linux-kernel - Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2N4g9FjmTBDBYGrGtY1XxGFRhOB+rMkhvwXUtSJOR+bg@mail.gmail.com>
Date:   Wed, 20 Dec 2017 15:22:45 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Russell King <linux@...linux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with
 future gcc

On Wed, Dec 20, 2017 at 2:46 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 20 December 2017 at 13:00, Arnd Bergmann <arnd@...db.de> wrote:
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX relocations
>> in loadable modules and converts bx instructions into mov even
>> when running on ARMv4T or ARMv5 processors. This is now redundant
>> when we pass --fix-v4bx to the linker for building modules, but
>> I see no harm in leaving the current implementation and doing both.
>>
>
> Are you sure --fix-v4bx is taken into account during a partial link?

No. I made the patch a long time ago, so I don't remember what exactly
led me to this decision, but it should be fine as long as the linker
does the transformation at least once.

>> +tune-$(CONFIG_CPU_SA110)       =$(call cc-option,-mtune=strongarm110)
>> +tune-$(CONFIG_CPU_SA1100)      =$(call cc-option,-mtune=strongarm1100)
>>  tune-$(CONFIG_CPU_XSCALE)      =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>>  tune-$(CONFIG_CPU_XSC3)                =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>
> Shouldn't these two be updated as well?

All compilers that drop -mtune=strongarm110 support for now still support
mtune=xscale, so I don't think we need to change them. One thing we could
consider is passing -mtune=xscale when building for StrongARM, if that
produces better code than the default -mtune=arm7tdmi, but from looking
at the gcc-8 sources, it's not clear if that's better or worse. Neither arm7tdmi
nor strongarm have a custom cost function, but xscale has. The difference
between arm7tdmi and strongarm110 tuning is just the maximum number of
conditional instructions (5 vs 3).

A much bigger impact might be to tune for arm9e when building a kernel for
ARM926, no idea why we don't already do that (we do it for arm946, which
nobody really uses). Also, gcc has optimizations for many ARMv7-A cores
that we could use if we decide to make them known in Kconfig.

      Arnd