Naturally - however apparently we ship our packages with stripped libraries in them: and this causes gdb to become -far- less useful wrt. debugging almost anything: worse it's a regression - this used to work quite well.
Surely there is no conceptual reason why we can't walk back up the un-optimised [!] frame-pointer containing [!] code and give at least useful output where we have debuginfo; I would accept:
#0 0xffffe430 in __kernel_vsyscall ()
#1 0x400db0f0 in __nanosleep_nocancel () from /lib/libc.so.6
#2 0x400daefe in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138
#3 0x0804858b in ??
#4 0x080485a5 in ??
#5 0x4001e4ac in trace_two (fn=0x804858d <trace_one>) at two.c:8
#6 0x080485b9 in ??
#7 0x080485d1 in main ()
but not giving up as we do at frame #4.
Really - having a system that is extremely hard to debug, and requires the installation of tons of mostly redundant debuginfo packages makes life rather harder than it should be [ not to mention the horrible truncation of the trace ]
Can you re-consider the priority change ? the evo. guys complain like mad about this on SLED10 - it makes their lives hell wrt. debugging.
Naturally - however apparently we ship our packages with stripped libraries in them: and this causes gdb to become -far- less useful wrt. debugging almost anything: worse it's a regression - this used to work quite well.
Surely there is no conceptual reason why we can't walk back up the un-optimised [!] frame-pointer containing [!] code and give at least useful output where we have debuginfo; I would accept:
#0 0xffffe430 in __kernel_vsyscall () nocancel () from /lib/libc.so.6 unix/sysv/ linux/sleep. c:138
#1 0x400db0f0 in __nanosleep_
#2 0x400daefe in __sleep (seconds=0) at ../sysdeps/
#3 0x0804858b in ??
#4 0x080485a5 in ??
#5 0x4001e4ac in trace_two (fn=0x804858d <trace_one>) at two.c:8
#6 0x080485b9 in ??
#7 0x080485d1 in main ()
but not giving up as we do at frame #4.
Really - having a system that is extremely hard to debug, and requires the installation of tons of mostly redundant debuginfo packages makes life rather harder than it should be [ not to mention the horrible truncation of the trace ]
Can you re-consider the priority change ? the evo. guys complain like mad about this on SLED10 - it makes their lives hell wrt. debugging.