<div dir="ltr">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.<br>
<br>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.<br>
<br>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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 4, 2013 at 3:18 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<br>

<br>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.<br>

<br>Thanks,<div>- Dave</div></div>
</blockquote></div><br></div>