This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove ioperm etc. support for arm
- From: Florian Weimer <fweimer at redhat dot com>
- To: Phil Blundell <pb at pbcl dot net>
- Cc: Aaro Koskinen <aaro dot koskinen at iki dot fi>, libc-alpha at sourceware dot org
- Date: Wed, 26 Jun 2019 17:23:32 +0200
- Subject: Re: [PATCH] Remove ioperm etc. support for arm
- References: <20190529135135.rt3c5fhhser7fik6@hetzner.pbcl.net> <875zptqrwx.fsf@oldenburg2.str.redhat.com> <20190529141820.5nny64ugrvqyzqgd@hetzner.pbcl.net> <87r28hpb0l.fsf_-_@oldenburg2.str.redhat.com> <20190529184028.GC24195@darkstar.musicnaut.iki.fi> <87ef4hp08c.fsf@oldenburg2.str.redhat.com> <20190529201227.GD24195@darkstar.musicnaut.iki.fi> <87imttnewj.fsf@oldenburg2.str.redhat.com> <20190606215312.GB11598@darkstar.musicnaut.iki.fi> <87d0j0lap3.fsf@oldenburg2.str.redhat.com> <20190626150053.lwldsqs3j2ahbima@pbcl.net>
* Phil Blundell:
> On Wed, Jun 26, 2019 at 03:48:08PM +0200, Florian Weimer wrote:
>> * Aaro Koskinen:
>> > Just building with -march=armv4t should be enough for a start.
>>
>> This architecture doesn't have its own target triplet, right?
>
> Right. You can configure with "armv4t-unknown-linuxgnueabi" if
> you like but I don't think the glibc configury does anything
> different for "armv4t" than for plain "arm".
>
>> With the patch below, I get this in csu/init-first.os:
>>
>> 00000000 <__libc_init_first>:
>> 0: e12fff1e bx lr
>> 0: R_ARM_V4BX *ABS*
>>
>> But after linking, get this in libc.so.6:
>>
>> 000175a0 <__libc_init_first>:
>> 175a0: e12fff1e bx lr
>>
>> Does this mean I need to pass some other flags as well?
>
> No, that looks about right. ARMv4T does have "bx rN" so it
> is OK for that instruction to be generated. You might be
> thinking of ARMv4, which doesn't have bx at all and needs
> the linker to patch them (gcc passes --fix-v4bx from its
> specs when building for ARMv4) or the "blx" instruction
> which is only in ARMv5T and upwards.
Okay, so the patch is essentially complete?
I don't know if the code generation and relocation differences make this
a viable additional architecture build-only testing. Do you have an
opinion regarding this matter?
Thanks,
Florian