[fedora-arm] arm at lists.fedoraproject.org

[omalleys at msu.edu]

Quoting Nick Clifton <nickc at redhat.com>:

> Hi Everyone,
>
>   As part of a possible solution to the problem of how to bootstrap a
>   hard-float ARM Fedora port, I am working on a script to create "fat"
>   ARM binaries.  These are binaries which use the soft-float API, but
>   which contain a special section which holds a hard-float API
>   alternative.  Using one of the switches supported by the script it is
>   possible to flip over the binaries, so that they now use the
>   hard-float API and contain the soft-float API hidden away inside them.
>
>   This is still a work in progress, but we thought that it would be a
>   good idea to post the current version of the script to the list to see
>   what people think, and to gather any feedback.

I will give you my concerns :)

Is there a way to strip out What one you aren't using? IE i don't have  
an fpu, therefore I want to strip out the hardfpu code for a smaller  
binary.

What vfpu are the target? I thought the main reason why we didn't want  
hard fpu's was because of the differences, between them. Number of  
registers varied, etc. You can't really optimize for each of them and  
have any sanity.

Is this going into the compiler? ie you compile for arm and you get  
the resulting fat binaries?

If I have to run a script that changes the objects in the binaries, it  
screws up checksums and can cause all sorts of issues.

Im not sure I am quite using correct terminology, but Is there a way  
to bootstrap this? Like at program launch, I have an FPU that matches  
xyz. I can use hardfpu code without tinkering with the binaries?

We have objectX we compile it as objectX-hardv1 objectX-softfpv1. We  
have an FPU, so we need to use objectX-hardv1, and maybe next year we  
have a hardv2.

At program launch, there needs to be something that says, Hey I have a  
FPU v2 compatible, use object hardv2, then hardv1, and softfp, objects  
if they exist in that order. Maybe more extensible, and you can  
include a way for specific simd or mimd instructions also.

I think it ends up to be like a runtime linker but at the object level.

make sense? Im not convinced this is the best way to do it either.

I think overall it is a good beginning.