[patch] Support multiple comdat sections with the same name but different groups

[David Blaikie]

Previous version produced some test failures (sorry I hadn't spotted those
before sending it out), mostly due to various bits of code in
ELFObjectWriter relying on simply morphing the name of a section (stripping
rel(a) or ARM.exidx, etc, prefixes) to find its linked section. I've added
some hackish code in the few places that were the source of test failures
to pass the section name as well, but that's pretty fragile and I haven't
attempted to look at all the places where we do this name morphing so
there's probably other untested broken places.

Should we change the MCSectionELF to store a pointer to its linked section
instead of trying to derive it from the name? Otherwise we could at least
add a convenience function to MCSection to retrieve the group name (or the
empty StringRef) and try to ensure we pass it in all the places where we do
such derivation.

Side note: the reason I'm not propagating the SHF_GROUP flag through when
creating rel(a) sections is that GCC doesn't, it was the only major
difference I could find when comparing output with my change to GCC's. I
don't have any reason to believe it's harmful to do so, except for the
wasted bytes - so we can leave that in if it's preferred/there's a reason
to do so. I haven't found any wording in the ELF64 or other specs to
clearly indicate which way that should go.


On Fri, Oct 4, 2013 at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote:

> In working on DWARF type_units I came across a need to emit multiple ELF
> sections of the same name but in different comdat groups. The integrated
> assembler doesn't seem to cope with that, so I've taken a (completely
> uninformed and reductionist) hack at trying to add such support.
>
> This has mostly been driven by a pure "what code changes cause LLVM to
> produce the desired output/pass the test", so I make no claims that is
> right or complete, just the best effort with limited knowledge. I'd
> appreciate any advice on how better to go about this or other test cases I
> haven't considered, etc.
>
> Thanks,
> - Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131008/c523f5f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comdat_group.diff
Type: application/octet-stream
Size: 7448 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131008/c523f5f4/attachment.obj>