dblaikie added a comment.

In D88603#2361010 <https://reviews.llvm.org/D88603#2361010>, @dblaikie wrote:

> In D88603#2360845 <https://reviews.llvm.org/D88603#2360845>, @dschuff wrote:
>
>> @sbc100 I found that the cause of the assertion is that 
>> in dwarf 5, the type units apparently go in the .debug_info section (instead 
>> of the .debug_type section), and this section already exists (but it was 
>> created as a non-comdat).
>> So when `getWasmSection` tries to look up an existing section it fails 
>> because the group is part of the key. Then it tries to create a new section 
>> but that fails because the name is duplicate.
>>
>> For some reason this doesn't happen or is not a problem with ELF but I 
>> haven't looked up why yet.
>> For now I just disabled the dwarf5+TU tests since we don't really use dwarf5 
>> yet anyway.
>
> for ELF, each {section name, hash} pair denotes a distinct section (when 
> using SHF_GROUP). Linker's deduplicate the group based on the hash, then 
> squish all the distinct sections with the same name together. (same system 
> that powers -ffunction-sections -fno-unique-section-names - even though each 
> function section is called ".text", because they have different hashes and 
> use SHF_GROUP, they are distinct sections in the object file)

Without similar behavior for wasm, how does wasm deduplicate these type units, 
if they're all in one section together? (have you tested this with two types? 
I'd expect that to hit the same problem - of attempting to create a section 
that already exists when it went to create the second type unit)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88603/new/

https://reviews.llvm.org/D88603

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to