[PATCH] D30129: Fix asm printing of associated sections

Evgenii Stepanov via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 21 14:49:43 PST 2017


On Tue, Feb 21, 2017 at 1:55 PM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>>> Why do you need both? Every section has a symbol associated with it, so
>>> you could use the section symbol for the relocation section link to the
>>> relocated section too.
>>
>> Because the section symbol can be redefined. For example, in
>>
>> .section x1,"a", at progbits
>> .local  x1
>> .comm   x1,4,4
>>
>> for section "x1", getBeginSymbol()->getSection() points to .bss.
>> Is that a bug, btw? We could replace getBeginSymbol() with an unnamed
>> symbol when it is redefined, but then there would be no way to
>> represent it in textual assembly.
>
> Yes, we should probably change this.
>
> My personal preference would be to just error in assembly if the name is
> reused (pr31850). If we can't do that and the non-section symbol has to
> win, the hard case is
>
> .section x1,"a", at progbits
> .quad x1
> .comm   x1,4,4
>
> since the expression of .quad already points to the given symbol. What
> needs to happen is for a new symbol to be created and be used as the
> section symbol.

Yes, with a quirk that starting at this point, the section symbol can
not be used in any context that would require printing it's name. This
kinda works for relocation sections, because they are never printed to
assembly. Still, that's confusing.

I think I like the idea of rejecting symbol redefinition in assembly.
The original problem in PR26941 was with LTO link, and it's not
present in ThinLTO. It sounds like no one cares about that case
anymore.

>
> Cheers,
> Rafael


More information about the llvm-commits mailing list