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

[Steve McIntyre <steve.mcintyre@xxxxxxxxxx>]

Thanks for the quick response!

On Sat, Oct 22, 2011 at 11:41:56PM +0000, Joseph S. Myers wrote:
>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.

OK. I don't think it's likely to fit there as it stands.

>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.)

Hmmm. Out of curiosity, why not? I can understand the potential for a
performance impact, but that doesn't show up in my testing.

>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.

Oh, absolutely. We've had some discussions about whether or not we
could make that work. In summary, we think it's *possible* but not
necessarily a good idea! In practice, there's nothing to be gained for
the extra complexity that will ensue.

>(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.)

OK...

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@xxxxxxxxxx
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches