Building armel on arm64

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

Building armel on arm64

Adrian Bunk-3
On Wed, Jun 27, 2018 at 08:03:00PM +0000, Niels Thykier wrote:
>...
> armel/armhf:
> ------------
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>    support uncertain. (DSA)
>...

I'd like to get a clear picture regarding the situation of building
armel for buster on arm64, ideally moving it to arm64 hardwre soon.


1. What issues are considered possible problems for moving building
   armel from 32bit v7 hardware to 64bit v8 hardware?

ARM has some history of adding new functionality in new versions of
their architecture that gets deprecated in the next version of their
architecture.

The armel baseline (currently armv5te) is low enough that several
of the issues with running armhf code on arm64 are not present
when running armel code on arm64.

If anyone sees potential blockers for building armel on arm64,
especially ones that are not present for building armhf on arm64,
please speak up now.


2. What level of testing has been done before building armhf on arm64?

64bit arm-arm-01 has started participating in building armhf for
unstable and experimental.

I don't want to do less testing for armel than has been done for armhf
prior to doing that, what testing had been done for armhf on arm64
building prior to doing it on a buildd?


3. Starting to build armel on arm64

Depending on the answers to the questions above I would like to
setup building armel on arm64, perhaps on the same arm-arm-01.


Thanks
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Steve McIntyre
Apologies for delayed response - I've been horrendously busy. :-/

On Sun, Jul 08, 2018 at 11:03:12PM +0300, Adrian Bunk wrote:

>On Wed, Jun 27, 2018 at 08:03:00PM +0000, Niels Thykier wrote:
>>...
>> armel/armhf:
>> ------------
>>
>>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>>    support uncertain. (DSA)
>>...
>
>I'd like to get a clear picture regarding the situation of building
>armel for buster on arm64, ideally moving it to arm64 hardwre soon.

ACK.

>1. What issues are considered possible problems for moving building
>   armel from 32bit v7 hardware to 64bit v8 hardware?
>
>ARM has some history of adding new functionality in new versions of
>their architecture that gets deprecated in the next version of their
>architecture.
>
>The armel baseline (currently armv5te) is low enough that several
>of the issues with running armhf code on arm64 are not present
>when running armel code on arm64.
>
>If anyone sees potential blockers for building armel on arm64,
>especially ones that are not present for building armhf on arm64,
>please speak up now.

I was worried about CP15 barriers, but I've been digging in docs for a
while and can't find anything to back that up for v5.

>2. What level of testing has been done before building armhf on arm64?
>
>64bit arm-arm-01 has started participating in building armhf for
>unstable and experimental.
>
>I don't want to do less testing for armel than has been done for armhf
>prior to doing that, what testing had been done for armhf on arm64
>building prior to doing it on a buildd?

Not very much *so far*. I wsan't expecting to find any issues, but at
least two clear issues have shown up so far:

 * Alignment fixups. We have these enabled on our v7 buildds, but
   there is no support for this at all in the arcm64 kernel. See
   #902990 as an example.

 * The definitions for MINSIGSTKSZ differ between armhf and arm64 -
   see #904385

To get an idea about these and any other problems, I've started a mass
rebuild of the archive as armhf-on-arm64 on three machines at
home. They're currently ~40% of the way through the archive and I
estimate they are going to take another couple of weeks to complete.

The next big problem I can see is in our haskell packages for
armhf. From my build log for haskell-zxcvbn-c_1.0.1-4.log (as an
example):

...
Setting up llvm-3.9 (1:3.9.1-19+b1) ...
Setting up ghc (8.2.2-4) ...
Illegal instruction

update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler (haskell-compiler) in auto mode
Illegal instruction
dpkg: error processing package ghc (--configure):
installed ghc package post-installation script subprocess returned error exit status 132
...

I'm going to have a look at that later today.

>3. Starting to build armel on arm64
>
>Depending on the answers to the questions above I would like to
>setup building armel on arm64, perhaps on the same arm-arm-01.

Possibly. Let's see how things go - I'm looking at sourcing many more
machines too...

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Adrian Bunk-3
On Tue, Jul 24, 2018 at 07:27:15AM +0100, Steve McIntyre wrote:

>...
> The next big problem I can see is in our haskell packages for
> armhf. From my build log for haskell-zxcvbn-c_1.0.1-4.log (as an
> example):
>
> ...
> Setting up llvm-3.9 (1:3.9.1-19+b1) ...
> Setting up ghc (8.2.2-4) ...
> Illegal instruction
>
> update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler (haskell-compiler) in auto mode
> Illegal instruction
> dpkg: error processing package ghc (--configure):
> installed ghc package post-installation script subprocess returned error exit status 132
> ...
>
> I'm going to have a look at that later today.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847#15

> >3. Starting to build armel on arm64
> >
> >Depending on the answers to the questions above I would like to
> >setup building armel on arm64, perhaps on the same arm-arm-01.
>
> Possibly. Let's see how things go - I'm looking at sourcing many more
> machines too...

Thanks. :-)

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Steve McIntyre
On Tue, Jul 24, 2018 at 11:22:36AM +0300, Adrian Bunk wrote:

>On Tue, Jul 24, 2018 at 07:27:15AM +0100, Steve McIntyre wrote:
>>...
>> The next big problem I can see is in our haskell packages for
>> armhf. From my build log for haskell-zxcvbn-c_1.0.1-4.log (as an
>> example):
>>
>> ...
>> Setting up llvm-3.9 (1:3.9.1-19+b1) ...
>> Setting up ghc (8.2.2-4) ...
>> Illegal instruction
>>
>> update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler (haskell-compiler) in auto mode
>> Illegal instruction
>> dpkg: error processing package ghc (--configure):
>> installed ghc package post-installation script subprocess returned error exit status 132
>> ...
>>
>> I'm going to have a look at that later today.
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847#15

Aha, thanks for the pointer! :-)

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Christoph Biedl-7
In reply to this post by Adrian Bunk-3
Adrian Bunk wrote...

> I'd like to get a clear picture regarding the situation of building
> armel for buster on arm64, ideally moving it to arm64 hardwre soon.

JFTR, I'd appreciate if armel/armhf could continue to be part of a
release.

> 1. What issues are considered possible problems for moving building
>    armel from 32bit v7 hardware to 64bit v8 hardware?

Perhaps just babble and FUD: There was (and probably still is) an issue
in powerpc: In a certain package, upstream's compile options for ppc had
higher CPU requirements than what Debian uses for that architecture. As
a result, the buildd (some big IBM POWER box) happily built the package,
but out there on a G4 the code would crash for SIGILL, same when
rebuilding on such a hardware.

Now I'm somewhat afraid this might happen again when packages for
armel/armhf are built on more recent hardware. At the same time, I'd
like to see continued support for these architectures.

If this is a concern, how to solve it? Have some native non-DSA
armel/armhf boxes where volunteers rebuild the archive and hope test
suites will catch such issues?

My 2¢

    Christoph

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Gene Heskett-4
On Tuesday 24 July 2018 14:43:02 Christoph Biedl wrote:

> Adrian Bunk wrote...
>
> > I'd like to get a clear picture regarding the situation of building
> > armel for buster on arm64, ideally moving it to arm64 hardwre soon.
>
> JFTR, I'd appreciate if armel/armhf could continue to be part of a
> release.
>
I'll second that, I'm using the hf variant on some r-pi 3b's.  And theres
millions of those around.

> > 1. What issues are considered possible problems for moving building
> >    armel from 32bit v7 hardware to 64bit v8 hardware?
>
> Perhaps just babble and FUD: There was (and probably still is) an
> issue in powerpc: In a certain package, upstream's compile options for
> ppc had higher CPU requirements than what Debian uses for that
> architecture. As a result, the buildd (some big IBM POWER box) happily
> built the package, but out there on a G4 the code would crash for
> SIGILL, same when rebuilding on such a hardware.
>
> Now I'm somewhat afraid this might happen again when packages for
> armel/armhf are built on more recent hardware. At the same time, I'd
> like to see continued support for these architectures.
>
> If this is a concern, how to solve it? Have some native non-DSA
> armel/armhf boxes where volunteers rebuild the archive and hope test
> suites will catch such issues?
>
> My 2¢
>
>     Christoph



--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

John Paul Adrian Glaubitz
In reply to this post by Christoph Biedl-7
On 07/24/2018 08:43 PM, Christoph Biedl wrote:
> Perhaps just babble and FUD: There was (and probably still is) an issue
> in powerpc: In a certain package, upstream's compile options for ppc had
> higher CPU requirements than what Debian uses for that architecture. As
> a result, the buildd (some big IBM POWER box) happily built the package,
> but out there on a G4 the code would crash for SIGILL, same when
> rebuilding on such a hardware.

If there are any packages with such an issue, it would be very helpful
if you could open bug reports with the following headers:

User: [hidden email]
Usertags: powerpc
X-Debbugs-CC: [hidden email]

> Now I'm somewhat afraid this might happen again when packages for
> armel/armhf are built on more recent hardware. At the same time, I'd
> like to see continued support for these architectures.

Not really. Unless Matthias Klose makes any changes to the baseline
configuration for gcc, this won't happen. Also, the evolution of
ARMv7 (Debian's armhf) would be ARMv8 and that wouldn't work inside
a 32-bit chroot or KVM environment. So, no, I don't think there is
any risk to run into this problem.

On PowerPC, the issue is usually related to AltiVec or the variations
of 64-Bit PowerPC. There are PowerPC variants by FreeScale that are
64 bit but don't support Altivec, for example. But again, if there
is any package which is affected by this problem, please let us know.

Oh, and in case of FPU instructions, you should make sure your kernel
has math emulation ebaled.

> If this is a concern, how to solve it? Have some native non-DSA
> armel/armhf boxes where volunteers rebuild the archive and hope test
> suites will catch such issues?

It's not a concern on ARM32 for the aforementioned reasons.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Adrian Bunk-3
In reply to this post by Christoph Biedl-7
On Tue, Jul 24, 2018 at 08:43:02PM +0200, Christoph Biedl wrote:

> Adrian Bunk wrote...
>
> > I'd like to get a clear picture regarding the situation of building
> > armel for buster on arm64, ideally moving it to arm64 hardwre soon.
>
> JFTR, I'd appreciate if armel/armhf could continue to be part of a
> release.
>
> > 1. What issues are considered possible problems for moving building
> >    armel from 32bit v7 hardware to 64bit v8 hardware?
>
> Perhaps just babble and FUD: There was (and probably still is) an issue
> in powerpc: In a certain package, upstream's compile options for ppc had
> higher CPU requirements than what Debian uses for that architecture. As
> a result, the buildd (some big IBM POWER box) happily built the package,
> but out there on a G4 the code would crash for SIGILL, same when
> rebuilding on such a hardware.
>
> Now I'm somewhat afraid this might happen again when packages for
> armel/armhf are built on more recent hardware. At the same time, I'd
> like to see continued support for these architectures.
>
> If this is a concern, how to solve it? Have some native non-DSA
> armel/armhf boxes where volunteers rebuild the archive and hope test
> suites will catch such issues?

This is not really a concern for a v7 -> v8 build change for armel.
stretch has a v4 baseline and v7 buildds.
buster has a v5 baseline.
I am not saying that baseline violations don't happen on armel (they do),
just that this change is unlikely to make a difference here.

For armhf this is actually a valid concern, especially regarding NEON.
NEON is not in the armhf baseline, and since our current buildd hardware
does not support NEON this catches plenty unconditional NEON usage.
One option for mitigating this problem would be to repurpose one
or more of the current buildd machines (there is even a spare)
for debci.
(Trying to use NEON on armel will give a compile error in any case.)

> My 2¢
>
>     Christoph

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Adam Borowski-3
In reply to this post by Christoph Biedl-7
On Tue, Jul 24, 2018 at 08:43:02PM +0200, Christoph Biedl wrote:
> If this is a concern, how to solve it? Have some native non-DSA
> armel/armhf boxes where volunteers rebuild the archive and hope test
> suites will catch such issues?

The problem is not doing the rebuilds, it's tuits to actually analyze and
report bugs.  There are multiple such efforts: reproducible builds use a
diverse bunch of hardware, I run a single Odroid-U2:
(arch:any) https://angband.pl/deb/rebuild.pl
(arch:all) https://angband.pl/deb/rebuild-all.pl
yet didn't have the tuits to go through them in several months.

Also, this machine does have neon so it's not even armhf baseline.  And so
many packages compile but don't test.  Thus, regressions from building on
arm64 need not just hardware but also manpowers to detect.


Meow.
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

John Paul Adrian Glaubitz


> On Jul 30, 2018, at 10:42 PM, Adam Borowski <[hidden email]> wrote:
>
> Also, this machine does have neon so it's not even armhf baseline.  And so
> many packages compile but don't test.  Thus, regressions from building on
> arm64 need not just hardware but also manpowers to detect.

But why should compiling ARMv7 on ARMv8 automatically change the baseline when it’s actually a hardwired configure option in gcc?

By the same logic, lots of the packages we build on ARMv7 machines for armel wouldn’t work on ARMv5.

Plus, we can build on the experience that openSUSE made with building ARMv6/7 on ARMv8. Why are we ignoring that?

Adrian
Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

Adam Borowski-3
On Mon, Jul 30, 2018 at 11:18:16PM +0200, John Paul Adrian Glaubitz wrote:
> > On Jul 30, 2018, at 10:42 PM, Adam Borowski <[hidden email]> wrote:
> >
> > Also, this machine does have neon so it's not even armhf baseline.  And so
> > many packages compile but don't test.  Thus, regressions from building on
> > arm64 need not just hardware but also manpowers to detect.
>
> But why should compiling ARMv7 on ARMv8 automatically change the baseline
> when it’s actually a hardwired configure option in gcc?

There's way too many packages that do compile-time detection.

> By the same logic, lots of the packages we build on ARMv7 machines for
> armel wouldn’t work on ARMv5.

And many probably don't, but such gear is so weak that a good part of
packages simply have no one running them.

> Plus, we can build on the experience that openSUSE made with building
> ARMv6/7 on ARMv8.  Why are we ignoring that?

How do you propose to do that other than sometimes digging through their
packaging for a patch here and there?


ᛗᛖᛟᚹ
--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Reply | Threaded
Open this post in threaded view
|

Re: Building armel on arm64

John Paul Adrian Glaubitz
On 07/31/2018 12:06 AM, Adam Borowski wrote:

> On Mon, Jul 30, 2018 at 11:18:16PM +0200, John Paul Adrian Glaubitz wrote:
>>> On Jul 30, 2018, at 10:42 PM, Adam Borowski <[hidden email]> wrote:
>>>
>>> Also, this machine does have neon so it's not even armhf baseline.  And so
>>> many packages compile but don't test.  Thus, regressions from building on
>>> arm64 need not just hardware but also manpowers to detect.
>>
>> But why should compiling ARMv7 on ARMv8 automatically change the baseline
>> when it’s actually a hardwired configure option in gcc?
>
> There's way too many packages that do compile-time detection.

Why has it never been an issue with PowerPC on PowerPC64 kernels, SPARC
on SPARC64 kernels, ARMv5 on ARMv7 kernels, MIPSEL on MIPS64EL kernels,
i386 on amd64 kernels and so on. It's not the first time at all that
we're building with a 32-bit userland on 64-bit kernels.

>> By the same logic, lots of the packages we build on ARMv7 machines for
>> armel wouldn’t work on ARMv5.
>
> And many probably don't, but such gear is so weak that a good part of
> packages simply have no one running them.

I disagree. Previous experience with other architectures as shown above
shows that it does work.

>> Plus, we can build on the experience that openSUSE made with building
>> ARMv6/7 on ARMv8.  Why are we ignoring that?
>
> How do you propose to do that other than sometimes digging through their
> packaging for a patch here and there?

SUSE is upstreaming usually everything. Also, I talked to Alex Graf who
is in charge of these things at SUSE and he confirmed me that building
of ARMv7 on ARMv8 is possible. He's also the one who fixed QEMU-KVM
issues with ARMv7 on ARMv8.

Oh, and SUSE also does extensive testing in OpenQA to make sure the
compiled packages actually work. So, I really think we can be confident
that building 32-bit ARM packages on 64-bit machines will actually
work the same way it does and did in the past for other architectures.

If you find a counter-example, I'd be very interested to learn about it,
I love finding new bugs after all :-).

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913