[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170501224456.GZ17319@brightrain.aerifal.cx>
Date: Mon, 1 May 2017 18:44:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Are there plans to support the "old" ABI (apcs-gnu) for
ARM?
On Tue, May 02, 2017 at 12:05:51AM +0200, Szabolcs Nagy wrote:
> * mzpqnxow <musl@...qnxow.com> [2017-05-01 16:11:10 -0400]:
> > I've seen it documented in several places that the so-called "old" ABI for
> > ARM (formally referred to as apcs-gnu, I believe) is not supported by musl,
> > though I haven't seen any formal explanation as to why. I'm wondering if
> > this is a design decision that has already been made or if it is just very
> > low priority on the TODO list- but might be implemented some day. I have a
> > need for an ARM OABI toolchain that allows me to statically link a good
> > amount of non-trivial executables and uClibc, glibc, etc. don't work for
> > me, mainly due to the reliance upon functions in the nss libraries which
> > need dynamic loading to function correctly.
> >
> > So I'm curious, will this "old" ARM ABI ever be supported/implemented in
> > musl or is it dead enough "in the wild" that it will never be implemented?
> > Also, if there is some way that I am missing something and the old ABI *is*
> > supported, I'd be happy for someone on the list to point out how I missed
> > it.
> >
> > A simple yes/no would be terrific, I don't need a long explanation of how
> > obsolete and slow the old ABI is- I am painfully aware. But here I am :>
>
> oabi would be a completely new port (even the syscall abi
> and type representations are different, not just the pcs)
>
> and it would be more work than a normal port because oabi
> has mixed endian double representation and the math code
> is not prepared for that (most double prec math code would
> need some fix).
>
> it's unlikely to be supported any time soon
I would add that it's unlikely to be accepted upstream since it's
obsolete and doesn't even have any maintained compilers that can
produce code for it (gcc dropped it years ago). If you need pre-armv4t
support, the right solution would be using -Wl,--fix-v4bx or maybe
-Wl,--fix-v4bx-interworking.
I'm not sure if there's an easy way to get old oabi kernels to run
such code; it's probably not too bad if you have the kernel source and
can rebuild, but may be quite hard if you can't easily replace the
kernel.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
