[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+qPFcJnMnM_acKb466FZ6qhSjg22zxHme0Y6aHS3qJoATUTVw@mail.gmail.com>
Date: Mon, 01 May 2017 22:31:20 +0000
From: Adam Greene <adam@...qnxow.com>
To: musl@...ts.openwall.com
Subject: Re: Are there plans to support the "old" ABI (apcs-gnu) for ARM?
Ah I wasn't aware it was so involved I haven't actually looked at the ABI
documentation, I've only written a small amount of self contained assembly
to do straight through system calls by hand- I thought it was just a matter
of syscall convention taking syscall numbers as an immediate instead of as
a register value. Clearly there's much more to it than that.
Thanks, I appreciate the detailed response.
On Mon, May 1, 2017 at 18:07 Szabolcs Nagy <nsz@...t70.net> 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
>
Content of type "text/html" skipped
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.
