Re: armv5 userland broken

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

On 2021/06/23 4:17, matthew green wrote:
> my first guess is this change:
>
> 2019-08-30  Bernd Edlinger  <bernd.edlinger%hotmail.de@localhost>
>
>          * config/arm/arm.md (unaligned_loaddi,
>          unaligned_storedi): New unspec insn patterns.
>          * config/arm/neon.md (unaligned_storev8qi): Likewise.
>          * config/arm/arm.c (gen_cpymem_ldrd_strd): Use unaligned_loaddi
>          and unaligned_storedi for 4-byte aligned memory.
>          (arm_block_set_aligned_vect): Use unaligned_storev8qi for
>          4-byte aligned memory.
>
> which is not in GCC 9.  the new gen_cpymem_ldrd_strd() seems to
> not look at current_tune->prefer_ldrd_strd, which should be 0
> for armv5.  or perhaps our default target is wrong for armv5 and
> this tune value is set to 1.

Yeah, this commit:

	https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3eefaaa9fe42837b1debc49575b4a5405bf0af3b

is most suspicious. But just reverting it together with

	https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d405dc23021fee4b6e1cd30650e0168b29918f61

as its dependent, results in no binary changes for ld.elf_so.

For target CPU:

On 2021/06/23 14:55, Nick Hudson wrote:
> On 22/06/2021 12:43, Rin Okuyama wrote:
> [snip]
>
> > So, my conclusions at the moment are:
> >
> > (1) GCC10 emits LDRD/STRD for unaligned memory operand for armv5,
>
> I think it's armv5te which is the reason that {ld,st}rd are getting
> generated.
>
> I think the attached patch is sensible as is changing from
>
>
>          *) target_cpu_cname="arm9e";;
>
> to arm9

arm9e, our target CPU for armv5, is the first processor family which
implements armv5te (and arm9 is armv4). GCC removed armv5{,e} support
from GCC9; all known processors are armv5t{,e} according to them.

We may have an option to choose arm10tdmi (armv5t processor family which
does not have {ld,st}rd instructions). Then, {ld,st}rd instructions are
not generated. But, I don't think {ld,st}rd theirselves are problematic
here; GCC9 also emits these instructions.

The problem is, GCC10 attempts to use these for operands not aligned to
8-byte boundaries. IMO, specifying ARM32_DISABLE_ALIGNMENT_FAULTS for
kernel makes things worse. ARMARM says:

| Prior to ARMv6, if the memory address is not 64-bit aligned, the data
| read from memory is UNPREDICTABLE. Alignment checking (taking a data
| abort), and support for a big-endian (BE-32) data format are
| implementation options.

for LDRD (ARM DDI 0100I, A4-51).

But, I may miss something...

Thanks,
rin