GDB backtraces on FreeBSD/Alpha

[Mark Kettenis <kettenis@wins.uva.nl>]

GDB backtraces have become seriously broken on -current.  

#0  main (argc=1, argv=0x11ffba80)
    at /home/kettenis/CVS/src/gdb/testsuite/gdb.base/return2.c:78
#1  0x120000678 in _start ()
#2  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#3  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#4  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#5  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#6  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#7  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#8  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#9  0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#10 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#11 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#12 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#13 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#14 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#15 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#16 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#17 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#18 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#19 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#20 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1
#21 0x160017404 in _rtld_start () from /usr/libexec/ld-elf.so.1

which goes on and on until GDB's backtrace limit is reached.  This is
pretty annoying and prevents me from running GDB's testsuite.

Backtraces work as expected on older executables.  The difference
between these older executables and the ones that produce these bogus
backtraces is the presence of an .mdebug section.  This section is
absent from the newer executables.  If present, GDB uses the info from
the .mdebug section to decide whether a frame corresponds to a
function in the object file that contains the entry point for the
program, and terminates the backtrace if it does.  Obviously this no
longer happens with the newer executables.

It is important to realize that the current system compiler still
generates bogus debug information.  So I'm actually only aiming at
making things work with GCC 3.0.x.

There are a couple of solutions for solving this problem:

* Make sure executables get back the .mdebug section.  However, it's
  not clear to me why they lost those sections in the first place.
  This is probably related to some changes in the toolchain, or in the
  way crt1.o is built.  Since I think that not emitting .mdebug unless
  the user specifically asked for debug information is actually the
  right behaviour, this probably isn't the right solution.

* Compile crt1.o with (minimal) debugging information.  With the
  current compiler this means we would get back the .mdebug section
  (and the minimal debug info generated by -g1 doesn't seem to be
  buggy).  With GCC 3.0.x (when it becomes the system compiler for
  -current in the future) we would get DWARF2 info, and I'm not
  entirely sure whether that works with the current GDB.  If it
  doesn't it can be fixed in GDB.  In that case using the current
  system compiler with -gdwarf-21 might also work.  The drawback of
  this approach is that all programs have to carry along a small
  amount of debug information.  Unless you strip them of course.

* Make sure the startup code in crt1.o clears the frame pointer.  This
  is what Linux/Alpha does.  IMHO, this would be the best way to solve
  this issue, since it is very robust.  However, it would involve
  rewriting (parts of) crt1.c in assembler.

Thanks,

Mark