search for: dw_at_signatur

Bunch of initially unrelated context: * type units can be referenced in a variety of ways: * DW_FORM_ref_sig8 on any attribute needing to reference the type * DW_AT_signature on a declaration of the type * extra wrinkle: the declaration can be nested into the appropriate namespace and given a name, or not * LLVM always does the "most expressive"/expensive thing: a full declaration (though without a name, but with the DW_AT_signature) in the correct namesp...

Hi debug-info folks, I've recently been experimenting with the -debug-info-kind=constructor model for debug-info creation, which is leading to some significant reductions in .debug_info on our large C++ benchmarks, which is great! I see in PR46537 that there's a plan to eventually enable this by default -- is this something we can target for LLVM12, or are there outstanding issues? While

...types are put into a separate type table and have hash-id, then it would be much easier to deduplicate them. The idea demonstrated here - https://reviews.llvm.org/P8164. (It still has a questions: whether base types should be put into type table, whether references into type table should be done by DW_AT_signature or just by offset, etc.. ) While handling that separate type table the DWARF aware linker would check the only hash_id and put only one type description with the same id in the final type table. It also would allow us to solve that -flto=thin problem - http://lists.llvm.org/pipermail/llvm-dev/202...

...have hash-id, then it would be much easier to >Alexey> deduplicate them. The idea demonstrated here - https://reviews.llvm.org/P8164. (It still has a >Alexey> questions: whether base types should be put into type table, whether references into type table >Alexey> should be done by DW_AT_signature or just by offset, etc.. ) While handling that separate type table >Alexey> the DWARF aware linker would check the only hash_id and put only one type description >Alexey> with the same id in the final type table. It also would allow us to solve that -flto=thin problem - >Alexey>...

...be much easier to >> >Alexey> deduplicate them. The idea demonstrated here - https://reviews.llvm.org/P8164. (It still has a >> >Alexey> questions: whether base types should be put into type table, whether references into type table >> >Alexey> should be done by DW_AT_signature or just by offset, etc.. ) While handling that separate type table >> >Alexey> the DWARF aware linker would check the only hash_id and put only one type description >> >Alexey> with the same id in the final type table. It also would allow us to solve that -flto=thin problem...

...exey> deduplicate them. The idea demonstrated here - https://reviews.llvm.org/P8164. (It still has a >>>> >> >Alexey> questions: whether base types should be put into type table, whether references into type table >>>> >> >Alexey> should be done by DW_AT_signature or just by offset, etc.. ) While handling that separate type table >>>> >> >Alexey> the DWARF aware linker would check the only hash_id and put only one type description >>>> >> >Alexey> with the same id in the final type table. It also would allow u...

...idea demonstrated here - > https://reviews.llvm.org/P8164. (It still has a > > >>>> >> >Alexey> questions: whether base types should be put into type > table, whether references into type table > > >>>> >> >Alexey> should be done by DW_AT_signature or just by offset, > etc.. ) While handling that separate type table > > >>>> >> >Alexey> the DWARF aware linker would check the only hash_id and > put only one type description > > >>>> >> >Alexey> with the same id in the final typ...

...>> >Alexey> deduplicate them. The idea demonstrated here - https://reviews.llvm.org/P8164. (It still has a >> >> >Alexey> questions: whether base types should be put into type table, whether references into type table >> >> >Alexey> should be done by DW_AT_signature or just by offset, etc.. ) While handling that separate type table >> >> >Alexey> the DWARF aware linker would check the only hash_id and put only one type description >> >> >Alexey> with the same id in the final type table. It also would allow us to solve that...

It makes me sad that the linker (via a library or otherwise) has to be "DWARF-aware" to be able to effectively handle --gc-sections, COMDATs, --icf etc for debug info, without leaving large blocks of data kicking around. The patching to -1 (or equivalent) is probably a good lightweight solution (though I'd love it if it could be done based on section type in the future rather than