Remove ioperm etc. support for arm

  * Aaro Koskinen:

> Hi,
>
> On Wed, May 29, 2019 at 11:12:44PM +0200, Florian Weimer wrote:
>> >> Maybe we used to test ARMv4, and GCC changed under us without us
>> >> noticing?
>> >
>> > Don't know if they have ever changed that, but it would probably make
>> > sense to add flags to build-many-glibcs.py to build for the lowest
>> > supported arch level.
>> 
>> Indeed.
>> 
>> > ARMv4 is already deprecated in GCC, so probably it's OK to remove this
>> > stuff from glibc. Personally I'm concerned about armv4t support as I'm
>> > running such systems still with modern glibc.
>> 
>> Interesting.  Could you perhaps suggest changes to build-many-glibcs.py
>> so that we can build an armv4t target as part of the regular runs?
>
> Just building with -march=armv4t should be enough for a start.

This architecture doesn't have its own target triplet, right?

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?

Sorry, I'm really not familiar with Arm at all.

Thanks,
Florian


build-many-glibcs.py: Add v4t variant for arm-linux-gnueabi

2019-06-26  Florian Weimer  <fweimer@redhat.com>

	* scripts/build-many-glibcs.py (Context.add_all_configs): Add v4t
	variant for arm-linux-gnueabi.
  

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.

p.
  

* 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
  

On Wed, Jun 26, 2019 at 05:23:32PM +0200, Florian Weimer wrote:
> Okay, so the patch is essentially complete?

I think so.  I will give it a try later and see if I can confirm
that it's doing the right thing, but assuming that the -march=
setting is indeed ending up on the compiler command line then I
think the answer is that the patch is correct.
 
> 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?

Yes, I think it's a useful test.  The assembler knows what instructions
are allowed in each architecture, so this build test is sufficient to
confirm (for example) that no blx instructions have leaked into the
generic ARM assembly sources without being suitably protected.

p.
  

* Phil Blundell:

> On Wed, Jun 26, 2019 at 05:23:32PM +0200, Florian Weimer wrote:
>> Okay, so the patch is essentially complete?
>
> I think so.  I will give it a try later and see if I can confirm
> that it's doing the right thing, but assuming that the -march=
> setting is indeed ending up on the compiler command line then I
> think the answer is that the patch is correct.

Thanks, that would be useful information to have.  If it all works out,
I will push my patch.

Florian
  

On Wed, Jun 26, 2019 at 05:56:15PM +0200, Florian Weimer wrote:
> * Phil Blundell:
> > I think so.  I will give it a try later and see if I can confirm
> > that it's doing the right thing, but assuming that the -march=
> > setting is indeed ending up on the compiler command line then I
> > think the answer is that the patch is correct.
> 
> Thanks, that would be useful information to have.  If it all works out,
> I will push my patch.

I (finally!) inspected the output from build-many-glibcs.py with your
patch and it looks correct for ARMv4T.  So I think you can go ahead
and push that.  Sorry it took me so long.

Thanks

Phil
  

* Phil Blundell:

> On Wed, Jun 26, 2019 at 05:56:15PM +0200, Florian Weimer wrote:
>> * Phil Blundell:
>> > I think so.  I will give it a try later and see if I can confirm
>> > that it's doing the right thing, but assuming that the -march=
>> > setting is indeed ending up on the compiler command line then I
>> > think the answer is that the patch is correct.
>> 
>> Thanks, that would be useful information to have.  If it all works out,
>> I will push my patch.
>
> I (finally!) inspected the output from build-many-glibcs.py with your
> patch and it looks correct for ARMv4T.  So I think you can go ahead
> and push that.  Sorry it took me so long.

Thanks, I've pushed my patch.

Florian