I've recently updated my watchdog wrapper script which starts D services to use gdb and disable rt_trapExceptions. My intention was to bypass D's standard exception handler and let gdb handle uncaught exceptions, and perhaps print better stack traces including function arguments and line numbers. However, this was the result:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000531f7c in rt.deh2.terminate() ()
#0  0x0000000000531f7c in rt.deh2.terminate() ()
No symbol table info available.
#1  0x00000000004ffebf in _d_throwc ()
No symbol table info available.
#2  0x0000000000000002 in ?? ()
No symbol table info available.
#3  0x0000000000000002 in ?? ()
No symbol table info available.
#4  0x000000000078e030 in ?? ()
No symbol table info available.
#5  0x000000000000001d in ?? ()
No symbol table info available.
#6  0x0000000000000002 in ?? ()
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

I assume that the stack frames under _d_throwc are not accessible because _d_throwc does not create a stack frame, as Druntime is built with -release but not -gs. (To clarify, stack frames are disabled by -release unless -gs is specified, in which case they're always emitted.)

Should the Phobos and Druntime makefiles be changed to include -gs in the release DFLAGS? I haven't noticed any difference in performance from timing the Druntime unittests. In theory, enabling it should provide a better out-of-the-box debugging experience at a negligible performance/filesize cost.

On 2012-12-04 08:47, Vladimir Panteleev wrote:
> I've recently updated my watchdog wrapper script which starts D services
> to use gdb and disable rt_trapExceptions. My intention was to bypass D's
> standard exception handler and let gdb handle uncaught exceptions, and
> perhaps print better stack traces including function arguments and line
> numbers. However, this was the result:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000531f7c in rt.deh2.terminate() ()
> #0  0x0000000000531f7c in rt.deh2.terminate() ()
> No symbol table info available.
> #1  0x00000000004ffebf in _d_throwc ()
> No symbol table info available.
> #2  0x0000000000000002 in ?? ()
> No symbol table info available.
> #3  0x0000000000000002 in ?? ()
> No symbol table info available.
> #4  0x000000000078e030 in ?? ()
> No symbol table info available.
> #5  0x000000000000001d in ?? ()
> No symbol table info available.
> #6  0x0000000000000002 in ?? ()
> No symbol table info available.
> #7  0x0000000000000000 in ?? ()
> No symbol table info available.
>
> I assume that the stack frames under _d_throwc are not accessible
> because _d_throwc does not create a stack frame, as Druntime is built
> with -release but not -gs. (To clarify, stack frames are disabled by
> -release unless -gs is specified, in which case they're always emitted.)
>
> Should the Phobos and Druntime makefiles be changed to include -gs in
> the release DFLAGS? I haven't noticed any difference in performance from
> timing the Druntime unittests. In theory, enabling it should provide a
> better out-of-the-box debugging experience at a negligible
> performance/filesize cost.

Isn't it better to ship Phobos and druntime with debug versions of the libraries as well.

-- 
/Jacob Carlborg

On Tuesday, 4 December 2012 at 12:11:37 UTC, Jacob Carlborg wrote:
> Isn't it better to ship Phobos and druntime with debug versions of the libraries as well.

Yes, providing something immediately usable with the -debuglib switch would be nice (I'd imagine a build without -O or -inline). However, if the performance impact of -gs is negligible, there's little reason not to enable it in the release version of Phobos. Those who want every 0.x% of performance can always build/write their own library.

On 12/5/2012 10:32 AM, Vladimir Panteleev wrote:
> On Tuesday, 4 December 2012 at 12:11:37 UTC, Jacob Carlborg wrote:
>> Isn't it better to ship Phobos and druntime with debug versions of the libraries as well.
> 
> Yes, providing something immediately usable with the -debuglib switch would be nice (I'd imagine a build without -O or -inline). However, if the performance impact of -gs is negligible, there's little reason not to enable it in the release version of Phobos. Those who want every 0.x% of performance can always build/write their own library.

If it's the right thing to be doing, the better question is 'why isn't it the default' and not an option that has to be turned on?

On Thursday, 6 December 2012 at 03:31:42 UTC, Brad Roberts wrote:
> On 12/5/2012 10:32 AM, Vladimir Panteleev wrote:
>> On Tuesday, 4 December 2012 at 12:11:37 UTC, Jacob Carlborg wrote:
>>> Isn't it better to ship Phobos and druntime with debug versions of the libraries as well.
>> 
>> Yes, providing something immediately usable with the -debuglib switch would be nice (I'd imagine a build without -O or
>> -inline). However, if the performance impact of -gs is negligible, there's little reason not to enable it in the release
>> version of Phobos. Those who want every 0.x% of performance can always build/write their own library.
>
> If it's the right thing to be doing, the better question is 'why isn't it the default' and not an option that has to be
> turned on?

That's a good question, but changing DMD switches is probably not worth it at this point.

I took a look at what GCC does:

"-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging."

That's interesting... so, at least in some situations, there is some way to get a proper stack trace without stack frames.

On Thursday, 6 December 2012 at 03:31:42 UTC, Brad Roberts wrote:
> On 12/5/2012 10:32 AM, Vladimir Panteleev wrote:
>> On Tuesday, 4 December 2012 at 12:11:37 UTC, Jacob Carlborg wrote:
>>> Isn't it better to ship Phobos and druntime with debug versions of the libraries as well.
>> 
>> Yes, providing something immediately usable with the -debuglib switch would be nice (I'd imagine a build without -O or
>> -inline). However, if the performance impact of -gs is negligible, there's little reason not to enable it in the release
>> version of Phobos. Those who want every 0.x% of performance can always build/write their own library.
>
> If it's the right thing to be doing, the better question is 'why isn't it the default' and not an option that has to be
> turned on?

Some debugger allow you to change the value of variables when the program is paused or some other similar stuffs. It require more information than simply the stack trace.