[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[Paul Walmsley]

ARMv7 builds now make use of the pldw opcode and the ".arch_extension mp"
pragma.  These aren't supported in binutils prior to 2.21.  So, update
Documentation/Changes accordingly.

Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

---
Intended for 3.13.

  Documentation/Changes | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/Documentation/Changes b/Documentation/Changes
index b175808..97fcbdf 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -67,6 +67,9 @@ assembling the 16-bit boot code, removing the need for as86 to compile
  your kernel.  This change does, however, mean that you need a recent
  release of binutils.

+ARMv7 builds require binutils 2.21 or later due to the use of the pldw
+opcode and ".arch_extension mp".
+
  Perl
  ----

-- 
1.8.1.5

[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[Russell King - ARM Linux]

On Wed, Oct 30, 2013 at 09:27:07AM -0700, Paul Walmsley wrote:
>
> ARMv7 builds now make use of the pldw opcode and the ".arch_extension mp"
> pragma.  These aren't supported in binutils prior to 2.21.  So, update
> Documentation/Changes accordingly.
>
> Signed-off-by: Paul Walmsley <pwalmsley@nvidia.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>

You can drop this Cc: line, thanks.

> Cc: Stephen Warren <swarren@nvidia.com>
> Cc: Thierry Reding <treding@nvidia.com>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> ---
> Intended for 3.13.
>
>  Documentation/Changes | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/Changes b/Documentation/Changes
> index b175808..97fcbdf 100644
> --- a/Documentation/Changes
> +++ b/Documentation/Changes
> @@ -67,6 +67,9 @@ assembling the 16-bit boot code, removing the need for as86 to compile
>  your kernel.  This change does, however, mean that you need a recent
>  release of binutils.
>
> +ARMv7 builds require binutils 2.21 or later due to the use of the pldw
> +opcode and ".arch_extension mp".
> +
>  Perl
>  ----
>
> -- 
> 1.8.1.5
>

[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[Rob Landley]

On 10/30/2013 11:27:07 AM, Paul Walmsley wrote:
> 
> ARMv7 builds now make use of the pldw opcode and the ".arch_extension  
> mp"
> pragma.  These aren't supported in binutils prior to 2.21.  So, update
> Documentation/Changes accordingly.

ARMv7 support didn't _exist_ in the minimal binutils version, and ARMv8  
support is newer still. Hexagon, microblaze, they've all shown up in  
newer versions than the one that will build older architectures.

Annotating the global Documentation/Changes with every per-arch  
requirement... not sure that's the right place for it.

I also note that the FSF's toolchain seems to be losing steam again,  
and this time around EGCS is called LLVM. Now that http://ellcc.org is  
self-hosting (and can even build native toolchains as of  
http://ellcc.org/blog/?p=251) all they need is http://lld.llvm.org to  
catch up and I think they've got a complete non-gnu toolchain capable  
of building a linux system. (It already contains musl-libc.org, I'm  
banging on toybox to provide a public domain busybox replacement...)

So there are larger issues in motion here. Noting armv7 requirements in  
an arm-specific file makes sense. Annotating the top level one raises  
the question of why not to do that for arc, unicore, openrisc, tile...

Rob

[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[Stephen Warren]

On 11/17/2013 11:50 AM, Rob Landley wrote:
> On 10/30/2013 11:27:07 AM, Paul Walmsley wrote:
>>
>> ARMv7 builds now make use of the pldw opcode and the ".arch_extension mp"
>> pragma.  These aren't supported in binutils prior to 2.21.  So, update
>> Documentation/Changes accordingly.
> 
> ARMv7 support didn't _exist_ in the minimal binutils version, and ARMv8
> support is newer still. Hexagon, microblaze, they've all shown up in
> newer versions than the one that will build older architectures.
> 
> Annotating the global Documentation/Changes with every per-arch
> requirement... not sure that's the right place for it.
...
> So there are larger issues in motion here. Noting armv7 requirements in
> an arm-specific file makes sense. Annotating the top level one raises
> the question of why not to do that for arc, unicore, openrisc, tile...

Documenting some of the requirements in the top-level file and some in a
per-arch file seems bad though. If we move the docs to a per-arch file,
we need to actively remove the top-level documentation since it will
conflict. What's wrong with a single table in the top-level document?
The answer to missing requirements for the other arch seems to be to
encourage the relevant maintainers to document them, not too disallow
the ARM requirements to be documented there.

[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[Rob Landley]

On 11/18/2013 10:56:39 AM, Stephen Warren wrote:
> On 11/17/2013 11:50 AM, Rob Landley wrote:
> > On 10/30/2013 11:27:07 AM, Paul Walmsley wrote:
> >>
> >> ARMv7 builds now make use of the pldw opcode and the  
> ".arch_extension mp"
> >> pragma.  These aren't supported in binutils prior to 2.21.  So,  
> update
> >> Documentation/Changes accordingly.
> >
> > ARMv7 support didn't _exist_ in the minimal binutils version, and  
> ARMv8
> > support is newer still. Hexagon, microblaze, they've all shown up in
> > newer versions than the one that will build older architectures.
> >
> > Annotating the global Documentation/Changes with every per-arch
> > requirement... not sure that's the right place for it.
> ...
> > So there are larger issues in motion here. Noting armv7  
> requirements in
> > an arm-specific file makes sense. Annotating the top level one  
> raises
> > the question of why not to do that for arc, unicore, openrisc,  
> tile...
> 
> Documenting some of the requirements in the top-level file and some  
> in a
> per-arch file seems bad though. If we move the docs to a per-arch  
> file,
> we need to actively remove the top-level documentation since it will
> conflict.

No, you just need to document arch-specific deltas in arch-specific  
files.

You can build Linux with gcc 3.4. There was no ARMv7 support in gcc 3.4  
(let alone 64 bit arm), but that doesn't change the fact that you can  
build Linux with it. Which is why it says "Upgrade to at *least* these  
software revisions".

If you're going to build Linux with llvm, you'll need a different  
version. If pcc manages to build linux (development of that's stalled  
but not stopped), then there's another one. If tinycc restarts...

> What's wrong with a single table in the top-level document?

So we haven't needed one for 20 years now, but your target is special?

The minimal requirements are the versions needed to build Linux at all,  
on any target, because there are generic features missing in earlier  
versions. Building Linux for a specific target often has more specific  
requirements.

> The answer to missing requirements for the other arch seems to be to
> encourage the relevant maintainers to document them, not too disallow
> the ARM requirements to be documented there.

There's a Documentation/arm directory but arm-specific documentation  
can't go there, it has to go at the top level even though other  
architectures haven't previously done this. The alternative is that any  
global documentation that does NOT apply to arm must be deleted to  
avoid confusing arm.

Is this really your position?

One of the 8 gazillion todo items I have queued up is moving  
Documentation/zorro.txt to the Documentation/m68k directory. That's not  
the same as deleting the file because its existence might confuse ARM  
developers. I honestly think most of them are smarter than that.

Rob

[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[Paul Walmsley]

Hi Rob,

On 11/17/2013 10:50 AM, Rob Landley wrote:
> On 10/30/2013 11:27:07 AM, Paul Walmsley wrote:
>> ARMv7 builds now make use of the pldw opcode and the ".arch_extension
>> mp"
>> pragma.  These aren't supported in binutils prior to 2.21.  So, update
>> Documentation/Changes accordingly.
> Annotating the global Documentation/Changes with every per-arch
> requirement... not sure that's the right place for it.

It doesn't matter to me where it's documented in the kernel 
documentation, but we should document it.

And we should expect folks who post patches with new toolchain 
constraints to also send patches for that documentation...

> Noting armv7 requirements in
> an arm-specific file makes sense. Annotating the top level one raises
> the question of why not to do that for arc, unicore, openrisc, tile...

Yes - it's the following x86-specific text in Documentation/Changes that 
inspired the patch:

-----
Linux on IA-32 has recently switched from using as86 to using gas for
assembling the 16-bit boot code, removing the need for as86 to compile
your kernel.  This change does, however, mean that you need a recent
release of binutils.
-----

But we can move that to Documentation/x86/ also.


regards,

- Paul

[PATCH] Documentation/Changes: update binutils version requirement for ARMv7 builds

[Rob Landley]

On 11/18/2013 02:06:18 PM, Paul Walmsley wrote:
> Hi Rob,
> 
> On 11/17/2013 10:50 AM, Rob Landley wrote:
>> On 10/30/2013 11:27:07 AM, Paul Walmsley wrote:
>>> ARMv7 builds now make use of the pldw opcode and the  
>>> ".arch_extension
>>> mp"
>>> pragma.  These aren't supported in binutils prior to 2.21.  So,  
>>> update
>>> Documentation/Changes accordingly.
>> Annotating the global Documentation/Changes with every per-arch
>> requirement... not sure that's the right place for it.
> 
> It doesn't matter to me where it's documented in the kernel  
> documentation, but we should document it.

Agreed, I'd just rather not add target-specific information to a file  
that currently has target-agnostic information.

A new file under Documentation/arm describing the build requirements  
for that platform would be nice. At some point I want to collate the  
target-specific directories under a Documentation/arch (so  
Documentation/arch/arm and Documentation/arch/m68k and so on, mirroring  
the source layout), but that's unrelated to this.

> And we should expect folks who post patches with new toolchain  
> constraints to also
> send patches for that documentation...

Agreed.

>> Noting armv7 requirements in
>> an arm-specific file makes sense. Annotating the top level one raises
>> the question of why not to do that for arc, unicore, openrisc,  
>> tile...
> 
> Yes - it's the following x86-specific text in Documentation/Changes  
> that inspired
> the patch:
> 
> -----
> Linux on IA-32 has recently switched from using as86 to using gas for
> assembling the 16-bit boot code, removing the need for as86 to compile
> your kernel.  This change does, however, mean that you need a recent
> release of binutils.
> -----

(Sigh, define "recent". Bisection search time, I suppose...)

> But we can move that to Documentation/x86/ also.

Agreed. Also the mcelog stuff looks x86-specific (or at least is  
currently documented as such). Also, I posted patches to remove the  
perl requirement but didn't remove the mention of perl from  
Documentation/Changes. I should fix that.

Also, Documentation/Changes is a weird name for the file describing the  
build environment requirements, but it's sort of grandfathered in at  
this point. That sort of implies I should add a  
Documentation/x86/Changes with the moved material, and the new arm file  
should be Documentation/arm/Changes. I suppose if the 00-INDEX  
clarifies that this describes the build environment requirements...

Which is worse, renaming a top level file that's been there for  
decades, or propagating the inaccurate name into subdirectories? Sigh,  
damned if you do...

Rob