Re: [Patches] ARM hard-float ABI - runtime linker checks

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Fri, 21 Oct 2011, Steve McIntyre wrote:

> I'm also concerned about how and where to link this code in. For now,
> I've just hooked into the end of elf/dl-load.c:open_verify() and put
> the code in the same file. I was hoping to find a cleaner way to add
> some architecture-specific checks here, but was disappointed to not
> find any. I'm thinking that this code would be better off in a
> separate file and linked appropriately, and guidance on ways to do
> that would be appreciated.

Certainly things need to go in a separate sysdeps file for the appropriate 
target (possibly ldsodefs.h), and libc-alpha would be the right forum to 
discuss how to hook in such checks in a generic way if it's not possible 
to hook it into the existing VALID_ELF_HEADER hook in some way.

An important question would be whether the attributes, an unloaded section 
in the section view of the file, are actually the right way to check this 
rather than using something in the segment view of the file.  HJ proposed 
creating a segment for attributes in 
<http://sourceware.org/ml/binutils/2007-08/msg00215.html>, but for various 
reasons this was rejected.  It was specifically noted in 
<http://sourceware.org/ml/binutils/2007-08/msg00384.html> that the 
attributes were intended only for static linker use and that such things 
as PT_ARM_ARCHEXT were more appropriate for dynamic linker use.

(Yes, when I implemented the GDB support for the hard-float ABI I made GDB 
check the attributes section of an executable to determine the appropriate 
ABI for it.  The section view of an executable or shared library, 
including its attributes, is certainly of use to various tools such as 
debuggers, but it's not intended for use by the dynamic linker.)

So it would seem a good idea to work out with the EABI committee how it 
seems most appropriate to make this information available for such 
checking - which I suspect will either be in the ELF header (which could 
probably be covered by VALID_ELF_HEADER) or in PT_ARM_ARCHEXT or another 
ARM-specific segment type (where maybe you could then add a macro tested 
in the existing loop over program headers, where it checks for PT_NOTE).  
The static linker would then generate the relevant information based on 
the attributes it merges from the input files.

When you do check, you know at compile time what's valid (depending on 
whether __ARM_PCS_VFP is defined) which should simplify the checks unless 
you're attempting to have one dynamic linker work for both ABIs - and 
while maybe that could theoretically work, sharing of object files between 
libc and ld.so probably makes building ld.so with a "don't care" ABI 
tricky in practice.

(I don't think the dynamic linker's ABI should depend on which ABI variant 
is in use, and as I noted at 
<http://sourceware.org/ml/libc-ports/2011-05/msg00002.html> the register 
preservation requirements are the same for both variants although problems 
with registers being clobbered are easier to demonstrate when those 
registers are used for argument passing.  If the dynamic linker is built 
with NEON enabled - whichever ABI is in use - it will sometimes get NEON 
code generated in it, although the only specific testcase I managed to 
produce for the problems with register clobbering involved a NEON memcpy.)

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches