Evgenii Stepanov via llvm-dev
2016-Mar-18 20:25 UTC
[llvm-dev] Handling of section vs global name conflicts
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.
Rafael Espíndola via llvm-dev
2016-Mar-21 14:55 UTC
[llvm-dev] Handling of section vs global name conflicts
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
Evgenii Stepanov via llvm-dev
2016-Mar-21 19:07 UTC
[llvm-dev] Handling of section vs global name conflicts
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
Joerg Sonnenberger via llvm-dev
2016-Mar-22 14:18 UTC
[llvm-dev] Handling of section vs global name conflicts
On Fri, Mar 18, 2016 at 01:25:17PM -0700, Evgenii Stepanov via llvm-dev wrote:> 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.Don't we have a similar case for STT_FILE already? Joerg
Rafael Espíndola via llvm-dev
2016-Mar-22 14:20 UTC
[llvm-dev] Handling of section vs global name conflicts
On 22 March 2016 at 10:18, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On Fri, Mar 18, 2016 at 01:25:17PM -0700, Evgenii Stepanov via llvm-dev wrote: >> 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. > > Don't we have a similar case for STT_FILE already?We do, yes. In summary my suggestion is doing something similar for STT_SECTION. Cheers, Rafael