This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]