Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: armv5 userland broken

On 26/06/2021 12:43, Rin Okuyama wrote:
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:


is most suspicious. But just reverting it together with


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:

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

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.

Ah, ok.

arm9 is indeed armv4 (gotta love marketing)

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...

 I was reading an ARMv6 ARM thinking it was ARMv5 and so I agree

ARM32_DISABLE_ALIGNMENT_FAULTS is a bad idea here.


Home | Main Index | Thread Index | Old Index