Re: [Ltib] libc backtrace and crash handlers

[Stuart Hughes]

Hi Kareem,

I should of phrased it better, what context are you in when you want the
backtrack, gdb native on the target, or are you using gdb/gdbserver.

Also the other thing that could possibly affect this is compilation
flags, for example (possibly) -fomit-framepointer

Regards, Stuart

Kareem Shehata wrote:
> On 2010-08-24, at 14:09 , Stuart Hughes wrote:
> 
>> Hi Kareem,
>>
>> The libc in LTIB is from the toolchain.  Normally this will be eglibc,
>> which is effectively glibc.
>>
>> What do you mean by a backtrace? do you mean a core file?  If so you may
>> need to change your ulimit settings, for example:
>>
>> # ulimit -c unlimited
> 
> 
> Hi Stuart,
> 
> A backtrace (aka stack trace) is a listing of which functions were called and 
> where.  As you can imagine, when debugging a program it's very useful to know 
> where exactly the problem occurred.  Here's an example from gdb:
> (gdb) bt
> #0  0x00009c98 in crashC (name=0x41a01d1c "Thread 3") at src/main.c:95
> #1  0x00009cc8 in crashB (name=0x41a01d1c "Thread 3") at src/main.c:99
> #2  0x00009cec in crashA (name=0x41a01d1c "Thread 3") at src/main.c:103
> #3  0x00009d9c in ecrash_test_thread (vparams=0x141b0) at src/main.c:123
> #4  0x400d3b3c in _pthread_cleanup_push_defer () from /lib/libpthread.so.0
> Backtrace stopped: frame did not save the PC
> (gdb) quit
> 
> I don't need it with all of the function names, just the hex address of the 
> location in the program (such as 0x00009c98), and I can use gdb to look up 
> what that actually means.
> 
> A core file is useful sometimes, but I'm trying to make it unnecessary to 
> send those by having my program print out what's actually needed.
> 
> Thanks,
> 
> Kareem
> 
> 
> --
> Kareem Shehata
> address@hidden
> Aeryon Labs Inc
> 519-489-6726 x254
> 
>