[lug] good assert library

[Chan Kar Heng]

>I compiled this via "gcc -g -rdynamic bt.c -o bt", and ran it:
>> ./bt
>Obtained 5 stack frames.
>./bt(print_trace+0x14) [0x80486c4]
>./bt(dummy_function+0xb) [0x8048747]
>./bt(main+0xb) [0x8048757]
>/lib/libc.so.6(__libc_start_main+0x90) [0x400461c4]
>./bt(backtrace_symbols+0x3d) [0x80485d1]
>
>
>In my case, it is showing actual frame names. I'm using Redhat's 2.96. I also tried with "-O0", it still worked, as well as "cc -Wl,--export-dynamic -g -Wall -O0 -o bt bt.c", which also worked. If I run ldd on the executable, I get:
>> ldd bt
>        libc.so.6 => /lib/libc.so.6 (0x4002f000)
>        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
>...so it isn't linking anything special, e.g., it is not linking a debug version of glibc. I wonder if perhaps your compiler version simply doesn't support it, or maybe the linker or glibc version does not support this. If I run "nm" on this executable, I get:

:)
i took a look at the specs file and found out that -rdynamic gets
translated to -Wl,--export-dynamic...
-O0 was to make sure that no optimization was turned on..
besides that, the only thing left was to make sure the symbols
are intact... which was shown by nm...

anyway, oddly enough, when i did an ldd, the results were
identical!

hmm... the only difference is that i'm using gcc 2.91 while you're
using gcc 2.96.

if i'm not mistaken, i have redhat 6.2 installed on my system..
rather old.. perhaps time for an upgrade. :)



>Oddly enough, these are almost identical, and indicate the same glibc and other functions. I do have a debug glibc installed on my system, but it is not linked against that, so I doubt it would have any effect. For reference, here is the RH output for gcc -v:
>Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
>gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
>
>I am guessing that there is an ABI (application binary interface) difference between our compiler versions which causes the backtrace to fail to read symbolic names correctly...it may not have been supported on your particular gcc version. If that were the case, it would likely become confused as to what part is the symbol text name. I'm not sure who you could ask about whether the backtrace() and backtrace_symbols() functions break on earlier ABI's or compilers, but I can't think of any other issue which would cause it to fail.

i agree with your diagnosis...
i suppose an upgrade is the best choice. :)


thanks again! :)

rgds,

kh