Comment 8 for bug 111869

So - let me get this right; are you stating that:

* in order to generate a useful backtrace - in future it is always going to be necessary to install debuginfo packages from the bottom of the trace upwards ?

That would suck some big rocks and was historically not the case.

Also - it would be interesting to know how valgrind [ if you replace the sleep() with (*(int*)0) = 0; ] manages to generate a useful debug log:

==21438== Process terminating with default action of signal 11 (SIGSEGV)
==21438== Access not within mapped region at address 0x0
==21438== at 0x8048584: (within /home/michael/gdb-testcase/a.out)
==21438== by 0x80485AF: (within /home/michael/gdb-testcase/a.out)
==21438== by 0x40294AB: trace_two (two.c:8)
==21438== by 0x80485C3: (within /home/michael/gdb-testcase/a.out)
==21438== by 0x80485DB: (within /home/michael/gdb-testcase/a.out)
==21438== by 0x40655F5: (below main) (libc-start.c:220)

ie. much as my suggested trace above. how does valgrind do it ? [ cf. coregrind/m_stacktrace.c (get_StackTrace_wrk) ] - it certainly doesn't give up almost immediately and actually gets to 'main' :-)

Why is it that we cannot simply follow the %ebp chain up and get a load of values for IPs for each function call point & make some educated guess (as valgrind does) ?

I've tentatively re-opened - if I'm just being totally dim witted here :-) please do re-close, but I would really like to better understand the necessity of prologue analysis when the code is compiled on IA32 with -O0 and no sillies (eg. -fomit-frame-pointer) - valgrind's backtrace appears rather simpler & more robust.