[Issue 9800] Numerous issues with DWARF debug output
https://issues.dlang.org/show_bug.cgi?id=9800 LucienPe changed: What|Removed |Added Status|NEW |RESOLVED CC||lucien.perreg...@gmail.com Resolution|--- |MOVED --- Comment #15 from LucienPe --- Status with DMD 2.093: 1. Fixed 2. Fixed 3. Not a bug 4. Fixed 5. Moved to https://issues.dlang.org/show_bug.cgi?id=21154 6. Not a bug 7. Moved to https://issues.dlang.org/show_bug.cgi?id=21155 8. Moved to https://issues.dlang.org/show_bug.cgi?id=21155 9. Fixed 10. Moved to https://issues.dlang.org/show_bug.cgi?id=21156 11. Not a bug 12. Moved to https://issues.dlang.org/show_bug.cgi?id=21157 13. Fixed 14. Not a bug 15. Fixed 16. Won't fix 17. Won't fix 18. Moved to https://issues.dlang.org/show_bug.cgi?id=21158 19. Moved to https://issues.dlang.org/show_bug.cgi?id=21159 20. Won't fix 21. Moved to https://issues.dlang.org/show_bug.cgi?id=21160 --
[Issue 9800] Numerous issues with DWARF debug output
https://issues.dlang.org/show_bug.cgi?id=9800 Mathias Lang changed: What|Removed |Added CC||mathias.l...@sociomantic.co ||m --- Comment #14 from Mathias Lang --- Where are we left with this ? A lot of improvement has been done to support D code in GDB, thanks to Iain. I kinda like the idea of having a DWARF / Debugging specific meta issue to link things to (that's what Hackerpilot did for the grammar issues). Any takers ? @ibuclaw ? :D --
[Issue 9800] Numerous issues with DWARF debug output
https://issues.dlang.org/show_bug.cgi?id=9800 --- Comment #13 from Iain Buclaw --- (In reply to Iain Buclaw from comment #1) > I'll post this in a few parts for ease of taking in, starting with the TL;DR. > > It is evident that dmd needs some loving on it's side, but I'll weigh in my > thoughts on behalf of gdc's implementation here: > > From what you have raised, this is the current state of play (in gdc) > > Fixed Bugs: #1 (with limitation to integral types), #9 > Identified Bugs: #7, #8, #10 These three identified bugs have been fixed in gdc+gdb. --
[Issue 9800] Numerous issues with DWARF debug output
https://issues.dlang.org/show_bug.cgi?id=9800 --- Comment #12 from Iain Buclaw --- (In reply to Iain Buclaw from comment #2) > > 7. DW_TAG_module is only valid for Fortran/Modula-2, but I'd argue that this > is a bug. It would be nice to represent statics as being part of a module, > my hope would be that adding support would mean that we'd no longer have to > use 'quotations' or the full mangled name to get/set global decls in the > debugger. Though it is worth noting that DWARF2 does not have DW_TAG_module. > > The next version of GDB (7.11, unless they do some bikeshedding of their versioning system) will include explicit support for this in D programs. And will also be able to discover if a bare named symbol is from an imported module, and even handles renamed module + symbol imports. However it still requires that DMD be able to emit debug code for this though. --
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800
--- Comment #11 from Iain Buclaw 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: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com --- Comment #10 from Andrei Alexandrescu 2014-01-10 17:29:57 PST --- bounty increased to $150 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 --- Comment #9 from Iain Buclaw 2013-12-02 23:57:45 PST --- (In reply to comment #8) > The DMD compiler generates the same DWARF info for both -g and -gc except for > DW_AT_language. This is the case since dmd v2.58; see issue 4180. Thanks for confirming! I only know that at one point in time this was not the case. :o) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 --- Comment #8 from Sarath Kumar Kodali 2013-12-02 21:24:58 PST --- The DMD compiler generates the same DWARF info for both -g and -gc except for DW_AT_language. This is the case since dmd v2.58; see issue 4180. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 --- Comment #7 from Iain Buclaw 2013-12-02 00:01:54 PST --- (In reply to comment #6) > All the problems listed are with DMD v2.6x when using -g switch. I have not > tried gdc or ldc, so cannot comment for them. > Snipping all your problems. I think the best thing to do with dmd's situation is to deprecate -gc and start moving the debug emission of types that differ in -gc into -g. Could you do a re-test with -gc also? > > 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 is fixed in my gdb fork - I'm just waiting for the assignment papers to come through. :-) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800
--- Comment #6 from Sarath Kumar Kodali 2013-12-01
23:44:08 PST ---
All the problems listed are with DMD v2.6x when using -g switch. I have not
tried gdc or ldc, so cannot comment for them.
1. enum : type is not represented as DW_TAG_enumeration_type
2. enum values are not represented.
DWARF v2.0 (section 5.6, page 45) states that enum types is represented as
DW_TAG_enumeration_type and the enumeration literal as DW_TAG_enumerator. Each
enumerator value is represented with DW_AT_const_value attribute.
DW_AT_const_value can be string, constant or block. However the standard says
only numeric constants are represented.
In DWARF v3.0, it is added that the enumeration type can have DW_AT_type to
represent the type of underlying data type.
So with both V2 and V3, we can represent the enum info properly. I'm not sure
whether any debugger makes an assumption that enums will be only numeric values
with DWARF v2.0.
Due to non-representation of enums, gdb v7.5 complains that it is an incomplete
type and we cannot print its value using print command.
(gdb) p uiType
$2 =
(gdb) p/x uiType
$3 = 0x0
(gdb) x/d &uiType
0xbfffed34: 1
(gdb)
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.
(gdb) list 5,5
5 auto names = [ "Foo", "Bar" ];
(gdb) p _D6dtypes5namesOAAya
$1 = {, , }
(gdb) ptype _D6dtypes5namesOAAya
type = struct _Array_uns long long {
unsigned length;
struct _Array_char *ptr;
}
(gdb) p _D6dtypes5namesOAAya.length
$2 = 3
(gdb) p _D6dtypes5namesOAAya.ptr
$3 = (struct _Array_char *) 0x8074b20
(gdb) p *_D6dtypes5namesOAAya.ptr
$4 =
(gdb) ptype _D6dtypes5namesOAAya.ptr
type = struct _Array_char {
unsigned length;
char *ptr;
} *
(gdb) x/2s 0x8074b20
0x8074b20: "Foo"
0x8074b24: "Bar"
4. strings are represented as DW_TAG_base_type + DW_ATE_unsigned instead of
DW_TAG_string_type
DWARF v2.0 (section 5.8, page 46) states that "Fortran is one of the languages
that has a string type." That does not mean it was meant for only Fortran.
gdb v7.5 fails to recognize dmd strings.
below is the snapshot of gdb session. The D code is compiled with dmd -g.
(gdb) l
101 }
102 }
103
104 int main(string[] args)
105 {
106 foreach (arg; args[1..$])
107 {
108 if (!(arg == names[0] || arg == names[1]))
109 return 1;
110 }
(gdb) s
108 if (!(arg == names[0] || arg == names[1]))
(gdb) p arg
$1 = 13835042378651533313
(gdb)
6. DW_AT_external is set even for static types
That was a mistake, I meant "private" types. Module private variables &
functions and class private functions are represented as DW_AT_external
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.
9. classes are represented as DW_TAG_structure_type instead of
DW_TAG_class_type
10. member functions are not represented as children of the aggregate, stuct or
class
I'm not sure in what way DW_TAG_interface_type is useful for debugging. I will
have to write some interfaces and check.
11. DW_AT_linkage_name should be used instead of DW_AT_MIPS_linkage_name
True, DW_AT_linkage_name is defined in DWARF v3.0. This is only a compliance
issue and does not affect debugging with gdb.
12. DW_TAG_decl_file and DW_TAG_decl_line are not produced for any symbol other
than DW_TAG_subprogram
13. For reference types DW_TAG_pointer_type is used instead of
DW_TAG_reference_type
Again, this is an issues for DMD v2.64. GCC does the right thing, so I would
expect GDC also does the right thing - I ha
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 --- Comment #5 from Iain Buclaw 2013-11-18 01:58:44 PST --- I am uploading a copy of gdb to my repository. Will be updating D support in line with what is listed here. I'll revert a previous comment, we do not require to set DW_AT_main_subprogram at all. GDB has a way to determine the language main program without this. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 --- Comment #4 from Iain Buclaw 2013-11-17 05:51:48 PST --- (In reply to comment #3) > In summary: > > Areas identified where a new DWARF tag/attribute may be required: > > DW_TAG_dynamic_array_type > DW_TAG_delegate_type > DW_TAG_associative_array I forgot that the ABI page included a mention of these in the form of (the now removed): DW_TAG_darray_type DW_TAG_delegate_type DW_TAG_aarray_type -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 --- Comment #3 from Iain Buclaw 2013-11-17 05:37:21 PST --- In summary: Areas identified where a new DWARF tag/attribute may be required: DW_TAG_dynamic_array_type DW_TAG_delegate_type DW_TAG_associative_array DW_AT_property If we agree that these are needed, then we will need to file them as appropriate at the DWARF Standard issues page for inclusion into DWARF 5 - I can do this if there are no takers. Areas identified where an existing DWARF symbol should be used: DW_TAG_shared_type DW_TAG_module DW_TAG_class_type DW_TAG_interface_type DW_AT_pure DW_AT_main_subprogram For any existing flags in the DWARF standard we agree to use, we should make a start towards implementing them in our respective backends. And in an ideal situation, another ticket should be raised against the DWARF standard to update the language-specific tags/attributes so that they also include a mention of being used by D too. Regards, Iain. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800
--- Comment #2 from Iain Buclaw 2013-11-17 05:24:14 PST ---
The long response:
1. DW_TAG_enumeration_type is only valid for integral types, and the gcc
backend assumes this is the case (you could blame C/C++). GDC implements this
for *named* enums only (this is an improvement made in the last 3 months).
Code:
module debug;
enum A : int { a = 42 }
---
Printing values in GDB:
(gdb) p (int)'debug.A.a'
$1 = 42
(gdb) p ('debug.A') 42
$2 = debug.A.a
2. Anonymous enums and manifest constants have their symbolic values removed by
the frontend.
Code:
enum Foo = 42;
auto foo = Foo;
enum { Bar = 1 }
auto bar = Bar;
---
What is sent to the glue/codegen by the frontend:
auto foo = 42;
auto bar = 1;
3. GDC emits DW_TAG_array_type - though I guess this is subjective, as a fixed
array of eg: int[4] is treated like a struct with 4 int fields.
4. DW_TAG_string_type is only valid for Fortran. I also see no reason for it
either. D strings are already specially handled in gdb so that all dynamic
arrays are formatted correctly in the printer command.
5. We could do this, and although DW_TAG_shared_type is known to GCC, it is not
emitted anywhere (time to send patches to GCC-proper :o)
6. In D, static != private. Static decls can be used outside the declared
module, ergo DW_AT_external is set.
7. DW_TAG_module is only valid for Fortran/Modula-2, but I'd argue that this is
a bug. It would be nice to represent statics as being part of a module, my
hope would be that adding support would mean that we'd no longer have to use
'quotations' or the full mangled name to get/set global decls in the debugger.
Though it is worth noting that DWARF2 does not have DW_TAG_module.
8. If you are referring to what I think you are, this will be fixed when #7 is
addressed.
module a
int foo;
---
module b;
import a;
int bar;
---
Halting the program at a breakpoint in module b:
# This works if current module scope is 'module b'.
(gdb) print bar
# 'foo' is outside our current module scope at this breakpoint.
(gdb) print a.foo
9. Yeah - that's a bug - I fixed it just now (because it was quick and easy).
You also forgot about DW_TAG_interface_type too, which I've also added in for
GDC.
10. Another bug, the frontend really needs to record this information like it
does for VarDeclarations fields (there should be a FuncDeclarations methods).
11. GDC already does this, but it is worth pointing out that DWARF3 does not
have DW_AT_linkage_name.
12. GDC sets input/source location on all decls, types, statements,
expressions, etc... Of course, any artificial or builtin symbol gets a magical
builtin location that is tied to DW_TAG_decl_file, but it is only in special
circumstances (eg: you are a D compiler developer) that you would be setting
breakpoints in artificial functions.
13. GDC emits reference types (classes and ref parameters/foreach declarations)
as DW_TAG_reference_type - if you spot any cases where this is wrong, do let
this be known with code examples.
14. C type names are all aliases defined in druntime (see #17).
15. According to the ABI page for DMD, this is as per design. For GDC, we emit
these as two field structs, represented as string, immutable(wchar)[], and
immutable(dchar)[] accordingly.
*BUG* - D types whose internal layout is a structure are represented as
DW_TAG_structure_type. This includes D arrays, delegates, and associative
arrays.
16. Anonymous unions/structs are flattened by the front-end when adding fields
to AggregateDeclaration::fields - I have raised this before as an
implementation issue. I have ran into ICEs in GCC backend in the past because
it did not expect two fields to be at the same location in a struct, but I
haven't managed to reproduce it at least in the last 2 years (something must be
hiding the bug somewhere).
struct A
{
int a;
union { int b, c }
}
---
What is sent to the glue/codegen by the frontend:
AggregateDeclaration::fields
=> dim = 3;
=> data = [a, b, c];
---
What would be more ideal information to be sent:
AggregateDeclaration::fields
=> dim = 2;
=> data = [a, __anonymous];
=> __anonymous::fields
=> dim = 2;
=> data = [b, c];
17. Likewise to #2 - the frontend removes all symbolic values to aliases. If
you require symbolic debugging information, use typedef (which is, er,
deprecated).
alias int MyInt;
MyInt foo = 42;
---
What is sent to the glue/codegen by the frontend:
int foo = 42;
18. GDC does not do this, but then again GDC does not reverse all non-variadic
arguments in its ABI.
19. DW_AT_pure is only valid for Fortran. GCC currently does not emit it (even
in fortran programs as far as I can see). The ability to warn about calling
impure functions from the debugger will need to be implemented separately in
gdb.
20. DW_AT_elemental is only valid for Fortran, and does not describe @property
at all. We would need a new flag such as DW_AT_property.
21. DW
[Issue 9800] Numerous issues with DWARF debug output
https://d.puremagic.com/issues/show_bug.cgi?id=9800 Iain Buclaw changed: What|Removed |Added CC||ibuc...@ubuntu.com --- Comment #1 from Iain Buclaw 2013-11-17 04:48:56 PST --- I'll post this in a few parts for ease of taking in, starting with the TL;DR. It is evident that dmd needs some loving on it's side, but I'll weigh in my thoughts on behalf of gdc's implementation here: >From what you have raised, this is the current state of play (in gdc) Fixed Bugs: #1 (with limitation to integral types), #9 Identified Bugs: #7, #8, #10 Not Bugs: #3, #4, #6, #11, #12, #13, #15, #18 Needs discussion: #2, #5, #14, #16, #17, #19, #20, #21 Now, lets discuss this in more detail... -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
