This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
ABI versions and ports (was: Re: PLT / non-PIC executable support for MIPS)
On Sun, 28 Mar 2010, Daniel Jacobowitz wrote:
> On Sun, Mar 28, 2010 at 08:16:54PM +0000, Joseph S. Myers wrote:
> > Given that it's only set for the executable, should we still say that
> > numbers higher than 1 are used for STB_GNU_UNIQUE (and STT_GNU_IFUNC if
> > MIPS gets support for that in future) on MIPS to avoid confusion? With 1
> > being accepted with ELFOSABI_SYSV but higher values only for
> > ELFOSABI_LINUX.
> >
> > (I don't actually see any static linker support to set the ABI versions
> > for STB_GNU_UNIQUE and STT_GNU_IFUNC that libc now checks for; I presume
> > that will be forthcoming in due course.)
>
> I'm not sure. I think this might be a good question to get Roland's
> opinion on... I do not see how having one copy of the file in ports,
> and another in glibc, should work. It has to be append-only.
As far as I can see:
* The file will be taken from an add-on if found there, else from libc;
only one copy will be used.
* Thus, a ports copy needs to include all definitions from the libc copy
that are relevant to ports targets. At present, this means
UNIQUE
IFUNC powerpc-*-linux*
because powerpc-* targets come from ports (soft-float) as well as libc.
* Although the patterns in libc-abis use wildcards such as i?86, they are
actually matching against $(base-machine)-$(config-vendor)-$(config-os),
and base-machine is a value that has been canonicalized by configure,
meaning that it will always be i386 for the above, and that the powerpc64
and sparc64 cases will never match. It might make more sense to use
$(abi-name) instead (in which case a new line would be needed in ports for
powerpcsoft-linux-gnu).
> Historically, we've used abiversion 1 already. So reusing it for
> UNIQUE does not seem like a good idea.
>
> If glibc is still not checking the abi version of the main executable,
> then that seems a serious problem. But that may not matter.
--
Joseph S. Myers
joseph@codesourcery.com