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
parent reply "Dicebot" <public dicebot.lv> writes:
Do you have "-L--export-dynamic" in you dmd.conf?
Jun 24 2013
parent reply "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
parent reply "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
parent reply 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
parent reply 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.


=20
 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.

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
parent reply 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
parent reply "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
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