Re: armelfp: new architecture name for an armel variant
I'm just reading into this more (and sorry for the top-replies but I'm
using GMail and.. I dunno why it's not doing it the other way)
I can't find a single document in my library on ARM EABI (r2.08), ELF
file format recommendations etc. which define which floating point ABI
is used in an ELF executable. Most of these were updated in October
2009 so, in terms of the CPUs we're talking about, they're pretty
current, and I made sure they were still current vis a vis the ARM
website.
Basically, when you get an ELF executable you know it's ARM, whether
it's little or big endian, and that's it. GCC obviously has far, far
more information available while the objects are full of information,
before linking, converting to ELF and potentially stripping.. ld.so
has absolutely zero possibility to know what to do with it. This is
fairly consistent with all other ARM docs about FPU calling
conventions going back to FPA and still valid for VFP, which state
that you should never need to mix softfp and hardfp, and they will
generate weirdness because they return values in different registers,
but nothing about them failing to link together. Even gcc could be
considered to be overly strict about the matter if you take the ARM
docs verbatim.
I may be wrong, I really really do hope I am wrong and I just missed
something, otherwise this could be a world of hurt for end users. One
mistaken package update (glibc for example) and their entire system is
going to go down a big black hole.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
On Thu, Jul 8, 2010 at 8:33 PM, Matt Sealey <neko@genesi-usa.com> wrote:
> In theory that should never happen! Mixing soft and hard abi objects should fail to link - either binutils is busted or ld.so is not checking.
>
> Soft and softfp are capable of being stuffed together because the data is always passed via integer registers or stack the same way but hardfp binaries... No way. Launching a hardfp binary on soft or softfp libc should fail nice and hard :)
>
> That said there is no hard requirement in the abi docs for it. Gcc will fail to link because it needs to collect together objects with the same abi - but I can't say the same about ld.so checking and to be honest I would not know where to look to check.
>
>
> On Jul 8, 2010, at 8:06 PM, Martin Guy <martinwguy@gmail.com> wrote:
>
>> On 7/9/10, Martin Guy <martinwguy@gmail.com> wrote:
>>> Any mistake by users trying to mix the regular armel packages and
>>> the hardfloat ABI ones would just fail immediately.
>>
>> Erm my mistake. *Should* fail immediately but don't.
>> I just ran some tests on Maverick hardfloat in a Debian armel
>> environment, and gcc-4.2 and 4.3 happily link -mfloat-abi=hard and
>> -mfloat-abi=soft objects together to give executables that return
>> complete rubbish.
>>
>> So it looks like a new arch name is necessary to stop people mixing
>> the package types. :(
>>
>> M
>
Reply to: