https://d.puremagic.com/issues/show_bug.cgi?id=9800
--- Comment #2 from Iain Buclaw <[email protected]> 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_AT_main_subprogram is only valid for Fortran. This could be seen as a reasonable suggestion. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
