Would you trade 0.1% in performance for a better debugging experience?

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 18 November 2014 at 16:49:55 UTC, Marco Leise wrote:
> Without fully understanding the issue, omitting the frame
> pointer on GNU amd64 systems is the default and is supposed to
> work using DWARF debug information. So there should be no need
> for a stack frame pointer, right?

Firstly, does DMD generate DWARF debug information in practice 
that's correct enough to substitute stack frames? As far as I can 
tell, it doesn't.

Second, there's still the argument that not every debugger and 
profiler can take advantage of the DWARF debug information. It's 
certainly nowhere as easy: from the technical point of view, but 
also from a legal one, considering that (IIRC) most libraries 
dealing with DWARF debug information are GPL or LGPL, meaning we 
can't use them in the D runtime. And indeed, for printing the 
stack trace for an unhandled exception, Druntime currently walks 
the stack frames:

https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L452-L478

There is also the libc backtrace function, which the D runtime 
apparently used at some point:

http://www.gnu.org/software/libc/manual/html_node/Backtraces.html

It was removed in this commit:

https://github.com/D-Programming-Language/druntime/commit/9dca50fe65402fb3cdfbb689f1aca58dc835dce4

The commit message doesn't seem to mention why the use of the 
backtrace function was removed. But from reading the function's 
documentation, it looks like it works in the same way (walking 
the stack frame pointers, i.e. also reliant on stack frames).