_ioperm support for Arm

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm (was: Re: _ioperm support for Arm)

Joseph Myers
On Wed, 29 May 2019, Phil Blundell wrote:

> On Wed, May 29, 2019 at 04:53:46PM +0200, Florian Weimer wrote:
> > So it looks like to me like a later architectue version.
>
> Yes, right.  build-many-glibcs.py seems to explicitly call out ARMv5TE and
> later, and it also builds at least one library with gcc's default
> architecture settings (which you get to choose at the point you build
> the compiler, and I think the default defaults have also changed at
> various points in the past).  But there's no explicit selection of
> anything older than ARMv5TE so I think we should assume it isn't getting
> tested.

The --with-cpu=arm926ej-s is essentially "default architecture but with
FPU", since you can't build for hard float now (GCC 8 and later) unless
you specify an architecture or CPU that imply the presence of an FPU, or
specify an explicit FPU selection.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: _ioperm support for Arm

Arnd Bergmann
In reply to this post by Joseph Myers
On Thu, May 30, 2019 at 6:25 PM Joseph Myers <[hidden email]> wrote:

>
> On Wed, 29 May 2019, Phil Blundell wrote:
>
> > You're correct that it isn't practical for an ARMv4 machine to be
> > EABI conformant because the EABI mandates interworking and ARMv4
> > doesn't have BX/BLX, but last time I looked glibc did still have
> > all the right conditional guards in place to allow for compilation
> > on an ARMv4 platform.  I haven't checked recently though and it's
>
> The EABI fully supports v4t (though I haven't tested glibc on v4t hardware
> for a few years), but not v4.  There are two ways in which there can be
> some limited support for the EABI on v4:
>
> * --fix-v4bx can be passed to the assembler and linker (and GCC does so
> automatically for v4).  When passed to the assembler, it results in
> R_ARM_V4BX relocations on BX instructions; when passed to the linker, it
> results in those instructions being rewritten into a form that works on v4
> (so the .o files are interworking-safe but can also be used on v4 if the
> linker option is used).  This is mainly useful in bare-metal contexts with
> static linking only; it's not so good in a dynamic linking context where
> linked Arm code in an executable might later get run with Thumb code in a
> shared library on a newer processor.

I think this is what the remaining Linux users on StrongARM and FA526
platforms do, but I don't know if they use glibc or not. Those might
still use shared libraries, but it would be safe to assume that they are
never mixed with interworking ones, as these machines tend to run
a custom cross-built-from-source distro.

You can still buy new products using the FA526 ARMv4 CPU such
as the Moxa 'ART' SoC, and a notable user base on StrongARM based
PDAs and 'Cortina Gemini' SoC NAS boxes running modern code
on them.

I expect that the coming gcc-10 release will drop armv4 CPUs after
gcc-9 dropped armv3, but it should still be possible to build user
space with -march=armv4t and --fix-v4bx.

       Arnd
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Aaro Koskinen
In reply to this post by Florian Weimer-5
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.

A.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Florian Weimer-5
* 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  <[hidden email]>

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

diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index c5821df25e..dacd116f8e 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -158,7 +158,9 @@ class Context(object):
         self.add_config(arch='alpha',
                         os_name='linux-gnu')
         self.add_config(arch='arm',
-                        os_name='linux-gnueabi')
+                        os_name='linux-gnueabi',
+                        extra_glibcs=[{'variant': 'v4t',
+                                       'ccopts': '-march=armv4t'}])
         self.add_config(arch='armeb',
                         os_name='linux-gnueabi')
         self.add_config(arch='armeb',
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Phil Blundell-3
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.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Florian Weimer-5
* 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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Phil Blundell-3
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.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Florian Weimer-5
* 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
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Phil Blundell-3
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

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Remove ioperm etc. support for arm

Florian Weimer-5
* 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
12