help with mixed frame info

[Andriy Gapon <avg at icyb dot net dot ua>]

Using FreeBSD I have possibly an unusual setup.  My base system libraries are
compiled with FreeBSD "base" gcc which is 4.2-ish and without debug information.
But many applications and their libraries are compiled with gcc 4.5.4 and with
debug information on as needed basis.

I use gdb 7.3.1 and gdb from trunk (e.g. 7.3.50.20111010-cvs at the moment).

If I get a crash somewhere in the code that is compiled with gcc 4.5, then
debugging works without any issues.
If I get a crash somewhere in system libraries code, e.g. in libc because of
abort(2) call, then it is problematic.

I am not sure if the mix that I have is actually supposed to work (especially
given that the system libraries do not have debugging info), but I hope that it
can be made to work.

An example.

~/devel/gdb/gdb/gdb stratagus ~/devel/cores/stratagus.2.core
GNU gdb (GDB) 7.3.50.20111010-cvs
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-freebsd9.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/stratagus...done.
[New process 102742]
Core was generated by `stratagus'.
Program terminated with signal 6, Aborted.
#0  0x0000000803acda5c in thr_kill () from /lib/libc.so.7
(kgdb) bt
#0  0x0000000803acda5c in thr_kill () from /lib/libc.so.7
#1  0x0000000803b66f1b in abort () from /lib/libc.so.7
#2  0x00000000005626ed in CleanExit () at
/home/avg/tmp/stratagus/src/video/sdl.cpp:333
#3  0x000000080136a605 in ?? () from /lib/libthr.so.3
#4  0x000000080136a6eb in ?? () from /lib/libthr.so.3
#5  0x00007ffffffff003 in ?? ()
#6  0x000000080136a610 in ?? () from /lib/libthr.so.3
#7  0x0000000000000000 in ?? ()

It is clear that after frame #1 the stack unwinding is going into the weeds.
And that frame is the last frame from libc, above it there is supposed to be a
frame from the application.

Curiously, this is a stack that FreeBSD base gdb produces (6.1-ish code):
#0  0x0000000803acda5c in thr_kill () from /lib/libc.so.7
#1  0x0000000803b66f1b in abort () from /lib/libc.so.7
#2  0x00000000005626ed in CleanExit () at
/home/avg/tmp/stratagus/src/video/sdl.cpp:158
#3  0x000000080136a605 in pthread_sigmask () from /lib/libthr.so.3
#4  0x000000080136a6eb in pthread_sigmask () from /lib/libthr.so.3
#5  0x00007ffffffff003 in ?? ()
#6  0x000000080136a610 in pthread_sigmask () from /lib/libthr.so.3
#7  0x0000000000000000 in ?? ()
#8  0xffffffff7ffefedf in ?? ()
#9  0xffffffffffffffff in ?? ()
#10 0x0000000000000000 in ?? ()
...
many many weird frames are skipped
...
#139 0x0000000000000000 in ?? ()
#140 0x0000000000000006 in ?? ()
#141 0x0000000000200206 in ?? ()
#142 0xffffffff7fffffdf in ?? ()
#143 0x000000080086f800 in ?? ()
#144 0x0000000803acda50 in _umtx_lock () from /lib/libc.so.7
#145 0x0000000803b66f1b in abort () from /lib/libc.so.7
#146 0x000000000053020d in CUnit::DeAssignWorkerFromMine (this=0x808a27c00,
mine=@0x80701ca00) at /home/avg/tmp/stratagus/src/unit/unit.cpp:130
#147 0x0000000000534717 in CleanUnits () at
/home/avg/tmp/stratagus/src/unit/unit.cpp:130
#148 0x0000000000449ec4 in CleanModules () at
/home/avg/tmp/stratagus/src/game/loadgame.cpp:94
#149 0x00000000004dc540 in Exit (err=0) at
/home/avg/tmp/stratagus/src/stratagus/stratagus.cpp:292
#150 0x0000000000004a33 in ?? ()
#151 0x000000000045cfa0 in gcn::Widget::setPosition (this=Could not find the
frame base for "gcn::Widget::setPosition(int, int)".
) at /home/avg/tmp/stratagus/src/guichan/widget.cpp:86
#152 0x00007fffffffc460 in ?? ()
#153 0x00000000004aed86 in GameLogicLoop () at
/home/avg/tmp/stratagus/src/stratagus/mainloop.cpp:99
Previous frame inner to this frame (corrupt stack?)

Very far from perfect of course, but at least something.
Initially this version of gdb produces exactly the same stack, but it looks like
it is able to miraculously find the correct application stack in the end.

I wonder if this problem has to do with differences in the formats for
describing stack frames between gcc 4.2 and gcc 4.5.

I would appreciate any hints, suggestions, etc.
I can provide any additional information about the binaries and is read to test
any patches.

Thank you.
-- 
Andriy Gapon