[Issue 9800] Numerous issues with DWARF debug output

Fri Feb 14 03:31:09 PST 2014

https://d.puremagic.com/issues/show_bug.cgi?id=9800

--- Comment #11 from Iain Buclaw <ibuclaw at ubuntu.com> 2014-02-14 03:30:53 PST ---
(In reply to comment #6)
> 3. arrays are represented as DW_TAG_structure_type instead of DW_TAG_array_type
> 
> dmd v2.64 emits DW_TAG_array_type for static arrays and "unsigned long long"
> for dynamic arrays. string literal arrays are represented as
> DW_TAG_structure_type.
> 
> There are advantages and disadvantages with representing arrays (static or
> dynamic) as DW_TAG_structure_type or DW_TAG_array_type. The advantage with
> DW_TAG_structure_type is that the @property fields of an array ("ptr" and
> "length") become accessible from the debugger. But each element has to be
> accessed separately like array.ptr[0]. With DW_TAG_array_type, all the array
> values can be printed with "print array" command but .ptr and .length becomes
> inaccessible. In any case, representing an array as "unsigned long long" is
> plain wrong. BTW, gdb v7.5 is confused with DW_TAG_structure_type for string
> literal array.
> 

This I think can be fixed in GDB itself.  The problem you are seeing is because
it enforces C/C++ rules to the statement:

print arr[1];

With the D expression parser I'm writing up (it's in YACC), it should be
possible to teach GDB that 'arr' could be an DW_TAG_array_type or
DW_TAG_structure_type.  If it's a DW_TAG_structure_type and the fields are
'ptr' and 'length' then we can re-write: arr[1]  =>  arr.ptr[1], and maybe go
one step even fancier and do bounds checking too!

> 7. symbols within a module are not children of DW_TAG_module
> 8. module name should be removed from global symbols if they are made children
> of module
> 
> Dwarf v2.0.0 has DW_TAG_module (section 3.2, page 25). Again the standard does
> not say that this is for Modula2 language only. Using this tag, one could
> represent D module "static this()" functions as module initialization code
> using DW_AT_low_pc and DW_AT_high_pc as described in the spec.
> 
> Dwarf v3.0 further enhanced this and allowed multiple initialization codes per
> module.
> 
> While this is getting fixed, the compiler should also emit
> "TAG_imported_module" for module imports.
> 

This is in the process of being fixed.  It may be interesting to know that
DW_TAG_module is not actually needed, as it is possible from GDB's side to
build the a lexical scope map of all symbols based on their demangled names
(split the string using '.' as the delimiter).

So ie: breakpoint at std.stdio.writeln.put.  A look-up of an unqualified
variable name will check the scope of put, writeln, stdio, std, and global
scope for a match.

> 
> 14. C type names are produced for DW_TAG_base_type instead of D type names (eg.
> _Bool, wchar_t, unsigned char)
> 
> This is a  huge issue, as the debugger does not understand D basic types bool,
> ulong, uint, ushort etc
> 

GDB Upstream now understands all basic types, so if there are continual
problems then it's a DMD problem and there's nothing I can do.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=94b1b47ee13476f376feddf808c63560c036cf1b;hp=6377854769ea85f2dd38aac9a9b11fded61245f3

> 21. DW_AT_main_subprogram should be emitted for _Dmain, so that the debugger
> knows that it is the starting function instead of main()
> 
> Below is gdb v7.5 session with code compiled with "dmd -g" or "dmd -gc"
> 
> gdb -q ./dtypes
> Reading symbols from dtypes...done.
> (gdb) start
> [skip]
> Temporary breakpoint 1, 0x08060313 in main ()
> (gdb)
>  bt
> #0  0x08060313 in main ()
> (gdb) tbreak _Dmain
> Temporary breakpoint 2 at 0x80600c1: file dtypes.d, line 106.
> (gdb) c
> Continuing.
> 
> Temporary breakpoint 2, _Dmain (args=13835038538950770689) at dtypes.d:106
> 106             foreach (arg; args[1..$])
> (gdb)
> 
> As can be seen, gdb thinks "main" is the start function instead of _Dmain.

This has been fixed in upstream GDB, and you didn't even need
DW_AT_main_subprogram.  :o)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=6377854769ea85f2dd38aac9a9b11fded61245f3;hp=3271ba660a6a8434b1ec32b88ba456e9287a89ac

Everything else in this report is a specific DMD-backend problem and either
can't be reproduced in GDC, or it is implemented that way because of how the D
Front-end implementation is designed (eg: No debug info for 'alias', non-scalar
enums, and manifest constants).

Maybe I should create a meta-bug for things that are being dealt with in this
report.

Infact, this report is quite an extensive mess, and should really be split into
21 separate bug reports to allow better tracking of what is fixed/not fixed.

Regards
Iain

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------