This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix libc-abis handling for add-ons
On Wed, 7 Apr 2010, Roland McGrath wrote:
> > I don't see how that would work in general. MIPS_PLT had its ABI version
> > before UNIQUE, so needs to come first, but if a ports architecture gets
> > IFUNC support in future then that postdates UNIQUE and so must go after
> > the target-independent definitions. So there isn't a single order of
> > concatenation for this; ports definitions may need to go both before and
> > after libc definitions.
>
> For the truly general case, we might indeed need to figure out something
> slightly more complicated. But for the present reality, I'm confused as to
> how this can be. Before now, no ld set EI_ABIVERSION. The first ld that
> ever will already supports STB_GNU_UNIQUE. So how can it possibly be that
> MIPS needs to put some other feature before UNIQUE?
_bfd_mips_post_process_headers has:
if (htab->use_plts_and_copy_relocs && !htab->is_vxworks)
i_ehdrp->e_ident[EI_ABIVERSION] = 1;
(And although formally this is only used with ELFOSABI_SYSV at present,
and will only be set for executables not shared libraries, interpreting
the value differently for ELFOSABI_SYSV and ELFOSABI_LINUX would still
seem excessively confusing. So it seems better to say that 1 is
MIPS_PLT, while UNIQUE is 2 on MIPS.)
I don't think any of the EI_ABIVERSION-setting code in BFD for other
architectures (that sets it to nonzero values) is relevant to glibc at
present.
--
Joseph S. Myers
joseph@codesourcery.com