Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 May 2017 00:05:51 +0200
From: Szabolcs Nagy <>
Subject: Re: Are there plans to support the "old" ABI (apcs-gnu) for

* mzpqnxow <> [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

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.