From owner-freebsd-alpha Sun Sep 9 5:55:23 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from amsfep14-int.chello.nl (amsfep14-int.chello.nl [213.46.243.21]) by hub.freebsd.org (Postfix) with ESMTP id B976237B403 for ; Sun, 9 Sep 2001 05:55:14 -0700 (PDT) Received: from delius.kettenis.local ([213.93.77.104]) by amsfep14-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20010909125123.CFQA25701.amsfep14-int.chello.nl@delius.kettenis.local>; Sun, 9 Sep 2001 14:51:23 +0200 Received: (from kettenis@localhost) by delius.kettenis.local (8.10.1/8.10.1) id f89CsrL00394; Sun, 9 Sep 2001 14:54:53 +0200 Date: Sun, 9 Sep 2001 14:54:53 +0200 From: Mark Kettenis Message-Id: <200109091254.f89CsrL00394@delius.kettenis.local> To: freebsd-alpha@freebsd.org Cc: gdb@sources.redhat.com Subject: GDB backtraces on FreeBSD/Alpha Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message