[PATCH] D94475: [MC] Emit ELF files with ELFOSABI_GNU if specified in triple

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 1 13:34:51 PST 2021


MaskRay added a comment.

In D94475#2493695 <https://reviews.llvm.org/D94475#2493695>, @MoritzS wrote:

> In D94475#2493461 <https://reviews.llvm.org/D94475#2493461>, @MaskRay wrote:
>
>> This is known. GNU as by default emits `ELFOSABI_NONE` on Linux - if it does not use any GNU extensioin. If the assembly uses STT_GNU_IFUNC/STB_GNU_UNIQUE, GNU as will switch to `ELFOSABI_GNU`.
>>
>> The patch improves the few cases but regresses other cases, so I am requesting changes. It is also unclear whether respecting the GNU behavior is strictly necessary (see gold https://sourceware.org/bugzilla/show_bug.cgi?id=17735). STT_GNU_IFUNC is GNU extension and it is adopted by some other OSes. I am not sure the `readelf -S` output is a justifying reason for this change.
>
> I agree with you that it may not be strictly necessary to set ELFOSABI_GNU just because a GNU extension like IFUNC is used. However, if you do use such an extension //and// explicitly use the x86_64-unknown-linux-gnu triple for example (which is how I found this), I think it makes sense to use ELFOSABI_GNU.
>
> The failing tests use *-gnu triples and still expect ELFOSABI_NONE, so that's why they fail.
>
> I can write more code that checks if any GNU extension are actually used. Only if they are and you are also using a *-gnu triple, it will then use ELFOSABI_GNU. Would you agree to that kind of behavior?

Yes. We may need to do so for at least SHF_GNU_RETAIN.
https://sourceware.org/pipermail/binutils/2021-March/115581.html

STT_GNU_IFUNC/STB_GNU_UNIQUE probably need the similar behavior but they are not urgent.

`static uint8_t getOSABI(const Triple &T) {` may need to be `static uint8_t getOSABI(bool UsedGnuAbi) {`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D94475/new/

https://reviews.llvm.org/D94475



More information about the llvm-commits mailing list