search for: debug_macro

On Wed, Oct 9, 2019 at 11:59 AM Robinson, Paul <paul.robinson at sony.com> wrote: > Welcome Sourabh, > > > > There are many bits of DWARF-5 that haven’t been implemented. > Got a short list, by chance? > I know there is currently no big push within Sony to “fill in the > corners” for v5, as we have been more focused on quality of debug info for > optimized

...*(.debug_typenames) } .zdebug_typenames BLOCK(__section_alignment__) (NOLOAD) : { *(.zdebug_typenames) } .debug_varnames BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_varnames) } .zdebug_varnames BLOCK(__section_alignment__) (NOLOAD) : { *(.zdebug_varnames) } .debug_macro BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_macro) } .zdebug_macro BLOCK(__section_alignment__) (NOLOAD) : { *(.zdebug_macro) } /* DWARF 3. */ .debug_ranges BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_ranges) } .zdebug_ranges BLOCK(__section_alignment_...

...alignment__) (NOLOAD) : > { > *(.zdebug_typenames) > } > .debug_varnames BLOCK(__section_alignment__) (NOLOAD) : > { > *(.debug_varnames) > } > .zdebug_varnames BLOCK(__section_alignment__) (NOLOAD) : > { > *(.zdebug_varnames) > } > .debug_macro BLOCK(__section_alignment__) (NOLOAD) : > { > *(.debug_macro) > } > .zdebug_macro BLOCK(__section_alignment__) (NOLOAD) : > { > *(.zdebug_macro) > } > /* DWARF 3. */ > .debug_ranges BLOCK(__section_alignment__) (NOLOAD) : > { > *(.debug_...

On Thu, Oct 10, 2019 at 1:18 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > Ah, thanks for the list - mostly I'm interested in cases where Clang's > > output is not valid DWARFv5 when requested - the new features DWARFv5 > > enables/allows but doesn't require are lower priority to me. Which I > > don't think too much is left - DWARFv5

Hello Everyone, I would like to have your thoughts on this. Overview of the problem =================== While implementing support for the DWARFv5 debug_macro section support in LLVM. I came across these holes: - The macros infrastructure in CLANG/LLVM is inherently tied to a particular version(v4 macinfo). For instance, consider this snippet from CLANG: Gen->getCGDebugInfo()->CreateMacro(getCurrentScope(), llvm::dwarf::DW_MACINFO_defin...

COFF lld doesn't support the linker script at the moment, and I'm sad to say that it is very unlikely to support that in the future. Linker script support is so huge that I can't imagine we really want it for COFF. GNU BFD linker supports it because the linker is built as an interpreter for the built-in linker script (and that's one of the reasons why GNU linker is by far more

Hello, I have a user who is trying to get LLD to link for the cygwin target: https://github.com/zig-lang/zig/issues/751 Currently the issue they are running into is needing to define a linker script, but the COFF driver (or MinGW driver) does not have support for that. Is there documentation or advice for how to use LLD to link for cygwin? As a starting point, which driver to use? Regards,

...debug_weaknames) } + .debug_funcnames 0 : { *(.debug_funcnames) } + .debug_typenames 0 : { *(.debug_typenames) } + .debug_varnames 0 : { *(.debug_varnames) } + /* DWARF 3 */ + .debug_pubtypes 0 : { *(.debug_pubtypes) } + .debug_ranges 0 : { *(.debug_ranges) } + /* DWARF Extension. */ + .debug_macro 0 : { *(.debug_macro) } + .debug_addr 0 : { *(.debug_addr) } + .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) } + /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) } +} diff --git a/usr/klibc/arch/ia64/pipe.S b/usr/klibc/arch/ia64/pipe.S index 8ecd972..ae31a3a 100644 --- a...

...debug_weaknames) } + .debug_funcnames 0 : { *(.debug_funcnames) } + .debug_typenames 0 : { *(.debug_typenames) } + .debug_varnames 0 : { *(.debug_varnames) } + /* DWARF 3 */ + .debug_pubtypes 0 : { *(.debug_pubtypes) } + .debug_ranges 0 : { *(.debug_ranges) } + /* DWARF Extension. */ + .debug_macro 0 : { *(.debug_macro) } + .debug_addr 0 : { *(.debug_addr) } + .gnu.attributes 0 : { KEEP (*(.gnu.attributes)) } + /DISCARD/ : { *(.note.GNU-stack) *(.gnu_debuglink) *(.gnu.lto_*) } +} diff --git a/usr/klibc/arch/ia64/pipe.S b/usr/klibc/arch/ia64/pipe.S index 8ecd972..ae31a3a 100644 --- a...

...things that might not be done include: > > Default location entry > Inline namespace attribute > Reference-qualified member functions > "auto" return type > Type/item alignment > Defaulted template parameter > Atomic type modifier > DW_OP_implicit_pointer > .debug_macro section > Typed expressions > Supplementary objects > Ah, thanks for the list - mostly I'm interested in cases where Clang's output is not valid DWARFv5 when requested - the new features DWARFv5 enables/allows but doesn't require are lower priority to me. Which I don't thi...

...s DTRT already. (linkers deduplicate debug_str - but can they be made to remove unreferenced strings too? in that cas ewe'd have an interesting tradeoff of maybe using FORM_strp rather than strx - if we wanted the linker to be able to drop strings from dropped function definitions, etc) > .debug_macro contents are not tied to functions and won't be fragmented. > > .debug_loclists and .debug_rnglists should be fragmentable the same > way as .debug_info; they exist only as extensions of .debug_info, and > the range list for the CU itself is merely a concatenated set of > contrib...

On Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own

...oo? in that cas ewe'd have an interesting > > tradeoff of maybe using FORM_strp rather than strx - if we wanted the > > linker to be able to drop strings from dropped function definitions, > > etc) > > Future refinements are quite possible! > > > > > > .debug_macro contents are not tied to functions and won't be fragmented. > > > > > > .debug_loclists and .debug_rnglists should be fragmentable the same > > > way as .debug_info; they exist only as extensions of .debug_info, and > > > the range list for the CU itself is m...

I also think that we should keep one representation of debug info in the LLVM IR. There would be a need to extend some of the debug info entries to support CodeView, but I think that most of the information generated today by Clang for Dwarf can be used for generating CodeView. I can think about two missing extensions that are needed to CodeView: 1. In Frontend: File Checksum, it is