Date: Mon, 8 May 2017 12:17:29 +0200 From: Waldemar Brodkorb <mail@...demar-brodkorb.de> To: musl@...ts.openwall.com Subject: Re: Are there plans to support the "old" ABI (apcs-gnu) for ARM? Hi, are you sure you use uClibc? Because uClibc does not use libnss. best regards Waldemar > Am 02.05.2017 um 17:49 schrieb mzpqnxow <musl@...qnxow.com>: > > I suppose what really kills me is the different system calling convention on Linux 2.4 (which in my case seems a hard requirement) not just the instruction set- but I realize now that musl does not aim to support 2.4 (which is perfectly reasonable, same as not supporting the ARM OABI- total obsolescence) > > Thanks again for the details and the ld flags, I wasn't familiar with them, I might be able to hack around things between the linker trick and a (pretty involved) binary patching or patches to musl I can whip up- lots of fun! > > I'll GPL whatever I come up with in case anyone else is interested but I realize it won't go into musl upstream without someone to support it. I don't have the time or expertise for bugfixes and/or QA, so that won't happen in sure. > > Unfortunately in my case I'm stuck on Linux 2.4 and ARM OABI for this "project" :/ > > I wonder if there's an easy way to work around requiring the NSS libs by just patching uClibc.. I was able to build what I needed with an older GCC and uClibc, aside from the NSS libs static linking warnings (sorry, a little off topic now) > >> On Mon, May 1, 2017 at 18:45 Rich Felker <dalias@...c.org> wrote: >> 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 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.