This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
backtrace/2157: Backtrace not working with programs build with dmd for the D-programming language.
- From: benoit at tionex dot de
- To: gdb-gnats at sources dot redhat dot com
- Date: 16 Aug 2006 09:46:09 -0000
- Subject: backtrace/2157: Backtrace not working with programs build with dmd for the D-programming language.
- Reply-to: benoit at tionex dot de
>Number: 2157
>Category: backtrace
>Synopsis: Backtrace not working with programs build with dmd for the D-programming language.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Aug 16 09:48:01 UTC 2006
>Closed-Date:
>Last-Modified:
>Originator: benoit@tionex.de
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
The D programming language compiles into native code. A set of GDB patches exist, which make name demangling for gdb (www.dsource.org/projects/gdb-patches). However, the stacktrace in gdb does not work. The following is made with the original gdb that comes with ubuntu.
I want to get a stacktrace in case of a trows exception. First I have to get the address of the language intern "throw" function, because gdb does have a problem with the identifier "_d_throw@4". After the exception is throw, the stacktrace is always only 2-5 items long and sometimes ends with the message "Previous frame inner to this frame (corrupt stack?)".
I attached the source of the file for the sample session and the binary of the executable.
frank@lingurke:~/Dater/D/src$ objdump -x t | grep throw
211 .gnu.linkonce.t_d_throw 00000217 0804dd74 0804dd74 00005d74 2**2
0804dd74 l d .gnu.linkonce.t_d_throw 00000000 .gnu.linkonce.t_d_throw
0804dd74 g F .gnu.linkonce.t_d_throw 00000217 _d_throw@4
frank@lingurke:~/Dater/D/src$ /usr/bin/gdb t
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) break *0x0804dd74
Breakpoint 1 at 0x804dd74
(gdb) run
Starting program: /home/frank/Dater/D/src/t
[Thread debugging using libthread_db enabled]
[New Thread -1210214720 (LWP 5126)]
[Switching to Thread -1210214720 (LWP 5126)]
Breakpoint 1, 0x0804dd74 in _d_throw@4 ()
(gdb) bt
#0 0x0804dd74 in _d_throw@4 ()
#1 0x08049474 in _D1t11myThrowFuncFZv () at t.d:16
#2 0xb7cdcf80 in ?? ()
#3 0xbf968c60 in ?? ()
#4 0x0804943f in _D1t13myRecurseFuncFiZv (recurse=0) at t.d:11
Previous frame inner to this frame (corrupt stack?)
(gdb)
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="t.d"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="t.d"