[llvm-dev] Handling of section vs global name conflicts

[Evgenii Stepanov via llvm-dev]

So, we emit both a global symbol for the global variable, and a local
symbol for the section, with the same name?
This would need to be fixed both in the integrated assembler and in GAS.
Is it even allowed? What would the symbol references bind to, when
both symbols are defined?

On Mon, Mar 21, 2016 at 7:55 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> The correct fix is probably to know that section symbols are local and
> just allow them to have any name.
>
> Cheers,
> Rafael
>
>
> On 18 March 2016 at 13:25, Evgenii Stepanov via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hi,
>>
>> currently LLVM does not handle the conflict between a section and a
>> global _definition_ with the same name well. A section defines a local
>> symbol with the same name (pointing to the start of the section).
>> Depending on the order of declarations, LLVM either silently overrides
>> the section symbol with the global, or crashes with
>> fatal error: error in backend: symbol 'xxx' is already defined
>> The latter happens when the conflicting global is emitted when the
>> section is already created.
>>
>> See https://llvm.org/bugs/show_bug.cgi?id=26941 for more details and motivation.
>>
>> I think it would make sense to disallow global definitions with the
>> same name as a section. Unfortunately, sections are not values, and it
>> makes it hard to track them (ValueSymbolTable could implement value
>> renaming in case of conflicts, but there is no direct way of knowing
>> if the section name is currently in use or not without rescanning the
>> module). Changing IR representation of sections just for this sounds
>> like overkill.
>>
>> Another option is to allow the conflict, and make the global always
>> override the section symbol. This is easy to do in the integrated
>> assembler, but it appears that GAS simply does not work this way.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev