[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+qPFcLFjW2zHGzMjNEvbpkjqVZbjd7hM5ALDqY8qrKJT2ys3g@mail.gmail.com>
Date: Tue, 09 May 2017 02:41:29 +0000
From: mzpqnxow <musl@...qnxow.com>
To: musl@...ts.openwall.com
Subject: Re: Are there plans to support the "old" ABI (apcs-gnu) for ARM?
It is quite possible (likely?) that for this specific build I carelessly
used the glibc version of the toolchain I had in a directory next to the
uClibc toolchain by mistake... oops. My only excuse is having built more
than a few dozen "different" statically linked executables for use on a
variety of embedded (old and new) devices in one day (i.e. MIPS(EL) MIPS-I,
II, III, IV SYSV, MIPS(EL) MIPS32 v1, rel2, ARMEL SYSV, ARMEL OABI, etc,
etc.
These toolchains are making be a bit dizzy ;)
Thanks for pointing this out, I'll check into it but I think you're correct
and if so, you've saved me from a medium-large sized headache.
On Mon, May 8, 2017 at 06:17 Waldemar Brodkorb <mail@...demar-brodkorb.de>
wrote:
> 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.
