Re: problem in glibc backtrace done inside nptl library

["Vinu Rajashekhar" <vinutheraj at gmail dot com>]

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,