This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: problem in glibc backtrace done inside nptl library
- From: "Vinu Rajashekhar" <vinutheraj at gmail dot com>
- To: "Neal H. Walfield" <neal at walfield dot org>
- Cc: libc-help at sourceware dot org
- Date: Tue, 17 Jun 2008 18:27:11 +0200
- Subject: Re: problem in glibc backtrace done inside nptl library
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=aSbaJnhNOwm28RxqR6ukuFcUwrR7YubE3FUhZAKxhTQ=; b=kZQ5Kd7qw7q6JDYuddFkxQsI6RCzrR27QMJ+pc2Reeqgj/dutceKBCbHAgjNodQ/n5 wPYBwGa5d9fr0PJtRMu4iEr4KDqSnK9qjJ4KFpNVJR9UYvcOY5gfa+hOhMMUzsav87L4 8ixBfYUNq+oFNbGoC6hxToNjJkaPiKOyGK68o=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=G6Tq1sT13tVY+zjrdEvVbNnakiCqpMUDrQ2UWdhjr6S5rvvGnK29KkRJmCP5t/OqFl Tb1sBrgzMgcj4GgK959d458Wk61SV4bpWYhWys4XUS/F8JvJcXHB1FX9/pETGVjnKoFs FUTamyKzuPpzSe1KgwnLHNBi675HTaQxAf16w=
- References: <c81a07350806170627x35bbe780q460fd2c576f0e3aa@mail.gmail.com> <874p7sqhmd.wl%neal@walfield.org> <c81a07350806170726wa8d5e1ev7e55a7abfc05e3a9@mail.gmail.com> <c81a07350806170817x5f423f32q50b4f4b5c50ac4f0@mail.gmail.com>
I used addr2line function and it is showing the functions,
but I used the -fno-inline and -fno-inline-functions in compiling the files
like pthread_mutex_init.c and other nptl files, is there something else
I need to add to make it not inline like in the linking stage ?
I couldnt use the -O0 flag because there is some problem during glibc build
if I use that.
On Tue, Jun 17, 2008 at 5:17 PM, Vinu Rajashekhar <vinutheraj@gmail.com> wrote:
> Well I have used -fno-inline and -fno-inline-functions while
> building the nptl library, and there is no change in the situation.
>
> Is there no other way of getting a better backtrace, is there no way of
> using the gdb API or something, because it is very essential for me to
> get the symbol names from the backtraces, that too in-program.
>
> On Tue, Jun 17, 2008 at 4:26 PM, Vinu Rajashekhar <vinutheraj@gmail.com> wrote:
>> hi,
>> I didnt try with addr2line, but I tried using dladdr
>> to try to figure out the symbol name and addr, and it
>> is also not able to do it, does that mean that the funciton is inlined ?
>>
>> If so should I add something to the nptl library build
>> to prevent inline functions like -fno-inline-functions ?
>>
>> On Tue, Jun 17, 2008 at 4:08 PM, Neal H. Walfield <neal@walfield.org> wrote:
>>> At Tue, 17 Jun 2008 15:27:38 +0200,
>>> Vinu Rajashekhar wrote:
>>>>
>>>> Hi,
>>>> I am working on adding some code to the nptl library,
>>>> the code is in C++ and I have added the code to the nptl library,
>>>> changed the makefiles to compile it with nptl.
>>>>
>>>> I have instrumented pthread_mutex_lock , which calls a function from my
>>>> code and inside I do a backtrace, but in the backtrace I dont get all
>>>> the function names.
>>>>
>>>> I want to know if the problem is because of the -rdynamic flag,
>>>> because I am using it
>>>> in both the build phase and compiling the binary and also I did the
>>>> ldd to confirm its using
>>>> the new libraries, compiled with my sources.
>>>>
>>>> Heres the backtrace I get after using backtrace_symbols
>>>>
>>>> /home/vinu/glibc/local/lib
>>>> /libpthread.so.0 [0xb7f11820]
>>>> /home/vinu/glibc/local/lib/libpthread.so.0 [0xb7f05e0e]
>>>> /home/vinu/glibc/local/lib/libpthread.so.0 [0xb7f05ff7]
>>>> /home/vinu/glibc/local/lib/libpthread.so.0(pthread_mutex_lock+0x90) [0xb7eef600]
>>>> ./a.out(thr_fn0+0x12) [0x80487a6]
>>>> /home/vinu/glibc/local/lib/libpthread.so.0 [0xb7eed347]
>>>> /home/vinu/glibc/local/lib/libc.so.6(clone+0x5e) [0xb7e749ae]
>>>>
>>>> I want to get the function names of the other functions. The funny thing is
>>>> gdb is able to do it, then why not glibc backtrace ?
>>>
>>> It may be that the functions that you are not seeing in your trace are
>>> inlined. This is because backtrace just returns the return addresses
>>> that are on the stack; inlined functions are not executed as the
>>> result of a call.
>>>
>>> It is possible from looking at the binary and the debugging symbols to
>>> figure this out. This is what gdb does. Another tool that also does
>>> this is addr2line. If this shows you what gdb shows you, then the
>>> above is likely your problem.
>>>
>>> Neal
>>>
>>
>>
>>
>> --
>> Vinu Rajashekhar,
>> 3rd Year Dual Degree Student,
>> Deptt of Computer Science & Engg,
>> IIT Kharagpur,
>> India.
>>
>
>
>
> --
> Vinu Rajashekhar,
>
--
Vinu Rajashekhar,
3rd Year Dual Degree Student,
Deptt of Computer Science & Engg,
IIT Kharagpur,
India.