[PATCH] D107861: [MC] Change ELFOSABI_NONE to ELFOSABI_GNU for STB_GNU_UNIQUE

Jessica Clarke via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 26 17:26:37 PDT 2021


jrtc27 added a comment.

In D107861#2968322 <https://reviews.llvm.org/D107861#2968322>, @MaskRay wrote:

> In D107861#2968314 <https://reviews.llvm.org/D107861#2968314>, @jrtc27 wrote:
>
>> In D107861#2968305 <https://reviews.llvm.org/D107861#2968305>, @MaskRay wrote:
>>
>>> In D107861#2968300 <https://reviews.llvm.org/D107861#2968300>, @jrtc27 wrote:
>>>
>>>> I'm concerned that this will turn ELFOSABI_FREEBSD objects into ELFOSABI_GNU ones, which can sometimes break things. This GNU extension is implemented by FreeBSD too so we shouldn't be forcing ELFOSABI_GNU, just avoiding ELFOSABI_NONE, and giving an error if you have a different ELFOSABI that doesn't support these things.
>>>
>>> This is not an issue. `llvm-mc -triple=x86_64-freebsd` sets ELFOSABI_FREEBSD. This overrides the implicit ELFOSABI_GNU.
>>>
>>> On FreeBSD, the default triple is set to *-freebsd.
>>
>> Ah I managed to gloss over the `OSABI == ELF::ELFOSABI_NONE` check when looking at the sole user of seenGnuAbi. In which case I see no problem with this from a FreeBSD perspective, the only thing I can think of is we silently allow these GNU/FreeBSD extensions for other OSABIs, not that I personally care about any of them.
>
> "the only thing I can think of is we silently allow these GNU/FreeBSD extensions for other OSABIs, not that I personally care about any of them" is exactly my thought with STT_GNU_IFUNC.
> It has been adopted by sufficiently many OSABIs, so I am undecided what to do with it.

Yeah... NetBSD for example supports it but I'm pretty sure binutils is going to give an error if you try to use it with ELFOSABI_NETBSD. No clue how things are working there for example... unless they don't use their OSABI any more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107861



More information about the llvm-commits mailing list