On Linux dmd outputs faulty debug info. On Windows optlink crashes when building code in debug. Current situation is a complete disaster.

On 31/03/10 10:41, Eldar Insafutdinov wrote:
> On Linux dmd outputs faulty debug info.

There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time.

> On Windows optlink crashes when building code in debug. Current
> situation is a complete disaster.

OPTLINK still has problems, hopefully this situation will improve as it gradually gets ported to C and eventually open sourced (or at least we can hope that happens ;)). If not I guess we need to either write a new linker, or a new backend for dmd so it can output COFF and use another linker.

Hopefully we can sort this situation out and get debug info for D on a par with C/C++ :)

On 31-mar-10, at 17:09, Robert Clipsham wrote:

> On 31/03/10 10:41, Eldar Insafutdinov wrote:
>> On Linux dmd outputs faulty debug info.
>
> There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time.
>
>> On Windows optlink crashes when building code in debug. Current
>> situation is a complete disaster.
>
> OPTLINK still has problems, hopefully this situation will improve as it gradually gets ported to C and eventually open sourced (or at least we can hope that happens ;)). If not I guess we need to either write a new linker, or a new backend for dmd so it can output COFF and use another linker.

a new backend like gcc (of gdc) or even better llvm (ldc)?
for linux that was already done, and for D 1.0 it works well (I am using linux x86_64).

and debugging normally works, even tango's stacktrace...

windows is indeed a different story (but I know some people use gdc).

> Hopefully we can sort this situation out and get debug info for D on a par with C/C++ :)

On 31/03/10 16:09, Robert Clipsham wrote:
> On 31/03/10 10:41, Eldar Insafutdinov wrote:
>> On Linux dmd outputs faulty debug info.
>
> There are several bugs in the debug info on linux, one of them I've
> fixed (for most cases ie. anything that requires phobos, I'm working on
> the other cases ie. anything that needs funky libraries that use a lot
> of complicated function pointers), and another one you've sent me a
> massive test case for which I'm working down to a manageable size for a
> bug report now (I'd have done it by now, your make file doesn't play
> nicely with my multilib system though ;)). Other than those 2 bugs I
> don't know what else is blocking debug info on linux... I'm becoming
> quite familiar with DWARF/dmd's backend code for DWARF through all this
> debugging, so if I can get these bugs fixed I'd be happy to work on any
> others while I have time.

Having played with the testcase you sent me, it isn't another bug. You were using -g instead of -gc, which won't work until debuggers support the D extensions to debug info. When using -gc it gives the error as reported in bug #3987, so it should work when that is fixed.

Am 31.03.2010 20:16, schrieb Robert Clipsham:
> On 31/03/10 16:09, Robert Clipsham wrote:
>> On 31/03/10 10:41, Eldar Insafutdinov wrote:
>>> On Linux dmd outputs faulty debug info.
>>
>> There are several bugs in the debug info on linux, one of them I've
>> fixed (for most cases ie. anything that requires phobos, I'm working on
>> the other cases ie. anything that needs funky libraries that use a lot
>> of complicated function pointers), and another one you've sent me a
>> massive test case for which I'm working down to a manageable size for a
>> bug report now (I'd have done it by now, your make file doesn't play
>> nicely with my multilib system though ;)). Other than those 2 bugs I
>> don't know what else is blocking debug info on linux... I'm becoming
>> quite familiar with DWARF/dmd's backend code for DWARF through all this
>> debugging, so if I can get these bugs fixed I'd be happy to work on any
>> others while I have time.
>
> Having played with the testcase you sent me, it isn't another bug. You
> were using -g instead of -gc, which won't work until debuggers support
> the D extensions to debug info. When using -gc it gives the error as
> reported in bug #3987, so it should work when that is fixed.

Does this mean, the -g option only works in compination with the ddbg debugger and all other debugger need the -gc option?
I need this to set a defaultsetting in codeblocks!

On 31/03/10 19:31, Matthias Pleh wrote:
>> Having played with the testcase you sent me, it isn't another bug. You
>> were using -g instead of -gc, which won't work until debuggers support
>> the D extensions to debug info. When using -gc it gives the error as
>> reported in bug #3987, so it should work when that is fixed.
>
> Does this mean, the -g option only works in compination with the ddbg
> debugger and all other debugger need the -gc option?
> I need this to set a defaultsetting in codeblocks!

Having never used ddbg I can't say if it supports -g or not (although it looks like it should). But yes, as far as I'm aware, all other debuggers need -gc to be used, unless they have had D support written for them (even gdb with the D patches doesn't support -g).

Eldar Insafutdinov wrote:
> On Linux dmd outputs faulty debug info.
> On Windows optlink crashes when
> building code in debug.

Is there a bugzilla for this? For example, I compile the entire test suite on Windows with debugging on, and no optlink crashes.

Robert Clipsham wrote:
> On 31/03/10 10:41, Eldar Insafutdinov wrote:
>> On Linux dmd outputs faulty debug info.
> 
> There are several bugs in the debug info on linux, one of them I've fixed (for most cases ie. anything that requires phobos, I'm working on the other cases ie. anything that needs funky libraries that use a lot of complicated function pointers), and another one you've sent me a massive test case for which I'm working down to a manageable size for a bug report now (I'd have done it by now, your make file doesn't play nicely with my multilib system though ;)). Other than those 2 bugs I don't know what else is blocking debug info on linux... I'm becoming quite familiar with DWARF/dmd's backend code for DWARF through all this debugging, so if I can get these bugs fixed I'd be happy to work on any others while I have time.

Please let me know when you have dwarf.c patches ready, and thank you for trying to figure this out.

On 31/03/10 21:37, Walter Bright wrote:
> Please let me know when you have dwarf.c patches ready, and thank you
> for trying to figure this out.

The first one is in bugzilla, you just need to comment out/remove the lines:

	abuf.writeByte(DW_AT_type);	abuf.writeByte(DW_FORM_ref4);

(at about line 1447, in the TYjfunc case of the switch statement in dwarf_typidx()). And:

	infobuf->write32(nextidx);	// DW_AT_type

At about line 1469 of dwarf.c. This fixes debug info for druntime, phobos, and a couple of test projects (the debug info looks identical to the equivalent output from clang too).

There is one case which this patch doesn't solve, and that's for function pointers in the form:

T function(U function(V)) foobar;

Where T, U and V are any type. If you look at the .debug_info produced by dmd (either before or after the above patch, use objdump --dwarf=info testFile), you will see that it ends up writing what is parsed as a DW_TAG_compile_unit after the second DW_TAG_formal_parameter, so it seems some stray bytes are getting written causing the 0x1 to be detected as the abbrev rather than what ever it was intended to be (I'm still looking into this).

Robert Clipsham wrote:
> The first one is in bugzilla,

Do you mean http://d.puremagic.com/issues/show_bug.cgi?id=1079 or another?