Re: Deciding new arm EABI port name
On Tue, 04 Apr 2006 12:43:29 +0300, Riku Voipio wrote:
> On Mon, Apr 03, 2006 at 10:28:29AM -0700, Daniel Gimpelevich wrote:
>> That is precisely why I am suggesting here that -mhard-float be dumped
>> altogether in favor of -msoft-float, but have the soft-float
>> implementation code be a shared object that can be replaced as needed.
>
> ..which would break backward compatability with current hardfloat libs
> and binaries.
That's only software compatibility, and AFAICT the kernel doesn't care and
will happily run both types of binaries.
>> > EABI is probably the answer to all those issues...
>
>> ...except backward compatibility, right?
>
> well, changing from -mhard-float to -msoft-float breaks backward
> compatablity too. Vincent Sanders had similar (but more sophisticated)
> transition plan, but turned out to be unimplementable because current
> hardfloat ABI, float return values are returned a fpu register.
OK, I found his post of 2005-09-29, and the plan seems to be largely a
chronological inversion of the idea that I have, with inevitable
chicken-and-egg issues in addition to the aforementioned ABI roadblocks.
Furthermore, he stated that the purpose of the plan was avoidance of what
I see as the real problem: the non-feasibility of dumping all built
binaries and starting from scratch. If sections of the archive could be
rebuilt with -msoft-float in stages, with binaries of different ABIs that
don't link together coexisting for a time, I think the impact of dumping
all built binaries could be made more palatable.
> Besides, EABI has actually been implemented, while a hardfloat
> libfloat is still at a idea stage.
Correct, but a softfloat libfloat is also a reality today, and can easily
be a shared object. Once all binaries use it, attention can be turned to
crafting drop-in hardfloat replacements for it that use the softfloat ABI.
The only real question as I see it would be whether such a gradual
replacement of all built binaries could be OK when a sudden need to
rebuild all of them is not.
Reply to: