www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - stack trace on linux amd64 ?

reply "deadalnix" <deadalnix gmail.com> writes:
Hi,

since I updated dmd 2.063.2, stack traces look like this :

object.Exception libd-llvm/libd/src/util/visitor.d(17): 
d.ast.type.IdentifierType is not supported.
----------------
../bin/sdc() [0x5d3bcf]
../bin/sdc() [0x5ca085]
../bin/sdc() [0x5c9fe3]
../bin/sdc() [0x5d4583]
../bin/sdc() [0x5d4159]
../bin/sdc() [0x5d4621]
../bin/sdc() [0x5ca3ca]
../bin/sdc() [0x5d3b33]
../bin/sdc() [0x5ca085]
../bin/sdc() [0x5c9fe3]
../bin/sdc() [0x596caa]
../bin/sdc() [0x5bc1f7]
../bin/sdc() [0x5c6d94]
../bin/sdc() [0x5bc04f]
../bin/sdc() [0x596b53]
../bin/sdc() [0x586b00]
../bin/sdc() [0x5943b3]
../bin/sdc() [0x5e0cc1]
/usr/lib/x86_64-linux-gnu/libphobos2.so.0.2(void 
core.thread.Fiber.run()+0x31) [0x7f79439117ed]
/usr/lib/x86_64-linux-gnu/libphobos2.so.0.2(fiber_entryPoint+0x68) 
[0x7f79439111dc]
[(nil)]
----------------

addr2line is able to help me, but it seems that druntime is 
unable to provide any debug info.

Before I still needed addr2line to get line numbers, but at least 
I had the file and the mangled function name.

How can get my stack trace back ?
Jun 24 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Do you have "-L--export-dynamic" in you dmd.conf?
Jun 24 2013
parent Martin Nowak <code dawg.eu> writes:
On 06/24/2013 04:54 PM, deadalnix wrote:
 Haaa, passing -export-dynamic to the linker did the trick.

Exporting symbols from the executable is an ugly solution to get stacktraces. It would be much better if we used the debug information instead. They also provides richer information like line numbers.
Jun 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 24 June 2013 at 14:37:16 UTC, Dicebot wrote:
 Do you have "-L--export-dynamic" in you dmd.conf?

Yes, but I'm not linking with dmd (dmd fork itself and don't free any memory, which so I have a huge dead program sitting in memory during all link time). How should I link my stuff to make that work properly ?
Jun 24 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 24 June 2013 at 14:52:29 UTC, deadalnix wrote:
 On Monday, 24 June 2013 at 14:37:16 UTC, Dicebot wrote:
 Do you have "-L--export-dynamic" in you dmd.conf?

Yes, but I'm not linking with dmd (dmd fork itself and don't free any memory, which so I have a huge dead program sitting in memory during all link time). How should I link my stuff to make that work properly ?

Haaa, passing -export-dynamic to the linker did the trick.
Jun 24 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jun 24, 2013, at 11:34 AM, Martin Nowak <code dawg.eu> wrote:

 On 06/24/2013 04:54 PM, deadalnix wrote:
 Haaa, passing -export-dynamic to the linker did the trick.

Exporting symbols from the executable is an ugly solution to get =

instead. They also provides richer information like line numbers. If I remember correctly, the issue there was that the runtime would need = to open the executable or map file and parse it, and it seemed a lot = more straightforward to simply make an API call. But if you're inclined = to submit a pull request...=
Jun 28 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 28 Jun 2013 11:12:25 -0700
schrieb Sean Kelly <sean invisibleduck.org>:

 If I remember correctly, the issue there was that the runtime would
 need to open the executable or map file and parse it, and it seemed a
 lot more straightforward to simply make an API call.  But if you're
 inclined to submit a pull request...

In the meantime the GCC guys have developed libbacktrace [1] for GCC 4.8 which does exactly that: map the executable, parse it and use the dwarf debug info and all that without malloc. We're currently integrating this into GDC [2]. Unfortunately it's not as easy to integrate into dmd: It uses libgcc, the libbacktrace library is not installed in the target system (it's only available at gcc build time, we then just link it statically into druntime) and you need a more advanced build system to check for BACKTRACE_SUPPORTED in C headers. [1] https://github.com/mirrors/gcc/tree/master/libbacktrace [2] https://github.com/D-Programming-GDC/GDC/pull/65
Jun 28 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 28 June 2013 at 20:00:52 UTC, Johannes Pfau wrote:
 Am Fri, 28 Jun 2013 11:12:25 -0700
 schrieb Sean Kelly <sean invisibleduck.org>:

 If I remember correctly, the issue there was that the runtime 
 would
 need to open the executable or map file and parse it, and it 
 seemed a
 lot more straightforward to simply make an API call.  But if 
 you're
 inclined to submit a pull request...

In the meantime the GCC guys have developed libbacktrace [1] for GCC 4.8 which does exactly that: map the executable, parse it and use the dwarf debug info and all that without malloc. We're currently integrating this into GDC [2]. Unfortunately it's not as easy to integrate into dmd: It uses libgcc, the libbacktrace library is not installed in the target system (it's only available at gcc build time, we then just link it statically into druntime) and you need a more advanced build system to check for BACKTRACE_SUPPORTED in C headers. [1] https://github.com/mirrors/gcc/tree/master/libbacktrace [2] https://github.com/D-Programming-GDC/GDC/pull/65

https://github.com/bombela/backward-cpp That may be relevant.
Jun 28 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 June 2013 06:42, deadalnix <deadalnix gmail.com> wrote:
 On Friday, 28 June 2013 at 20:00:52 UTC, Johannes Pfau wrote:
 Am Fri, 28 Jun 2013 11:12:25 -0700
 schrieb Sean Kelly <sean invisibleduck.org>:

 If I remember correctly, the issue there was that the runtime would
 need to open the executable or map file and parse it, and it seemed a
 lot more straightforward to simply make an API call.  But if you're
 inclined to submit a pull request...

In the meantime the GCC guys have developed libbacktrace [1] for GCC 4.8 which does exactly that: map the executable, parse it and use the dwarf debug info and all that without malloc. We're currently integrating this into GDC [2]. Unfortunately it's not as easy to integrate into dmd: It uses libgcc, the libbacktrace library is not installed in the target system (it's only available at gcc build time, we then just link it statically into druntime) and you need a more advanced build system to check for BACKTRACE_SUPPORTED in C headers. [1] https://github.com/mirrors/gcc/tree/master/libbacktrace [2] https://github.com/D-Programming-GDC/GDC/pull/65

https://github.com/bombela/backward-cpp That may be relevant.

If DMD wants to go down the route of pulling in third party dependencies. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jun 29 2013