[PATCH] D88603: [WebAssembly] Add support for DWARF type units

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 28 19:47:16 PDT 2020


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



More information about the llvm-commits mailing list