Re: armv5 userland broken

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

Finally, it turned out that the main cause is not GCC. Some library
routines do not align sp to 8-byte boundary.

By fixing these routines, armv5 works at a level where ATF completes!

However, unfortunately, there still remains a bug in GCC itself, which
results in SIGBUS in ld.elf_so for tests/lib/libc/tls/t_tls_dlopen.

DETAILS:

By adding additional printf to data_abort_handler(), I've found that
the alignment fault occurs for this ldrd:

----
/libexec/ld.elf_so:     file format elf32-littlearm

...

000053b0 <_rtld_symlook_list>:
...
    53c8:       e1cd83d8        ldrd    r8, [sp, #56]   ; 0x38
----

This is strange; EABI requires sp to be aligned to 8-byte boundary,
and if so, [sp, #56] cannot cause alignment faults.

I've examined assembler codes for userland libraries for arm:
common/lib/libc, csu, libc, compiler_rt, and libm, and found that
some routines in compiler_rt do not align sp correctly:

http://www.netbsd.org/~rin/arm_stack_align_compiler_rt.patch

Also, some routines in libc do not also in Thumb-mode userland:

http://www.netbsd.org/~rin/arm_stack_align_libc_thumb.patch

By fixing these, armv5 system works just fine, except for new
regression in tests/lib/libc/tls/t_tls_dlopen; the alignment fault
occurs in the above mentioned ldrd in ld.elf_so!

This seems a bug in GCC itself, since testf() in the test attempts to
call EABI runtime routines before sp is aligned:

----
t_tls_dlopen:     file format elf32-littlearm

...

00010ca0 <testf>:
   10ca0:       e92d40f0        push    {r4, r5, r6, r7, lr}
   10ca4:       ebffff4e        bl      109e4 <__aeabi_read_tp@plt>
   10ca8:       e59f41d0        ldr     r4, [pc, #464]  ; 10e80 <testf+0x1e0>
   10cac:       e24dd00c        sub     sp, sp, #12
...
----

This seems a GCC bug for armv5 and prior, that needs function call to
obtain TLS pointer. armv6 and later use coprocessor instruction to
get TLS pointer; coprocessor instruction can be always safely used
before sp is adjusted.

It seems that there are problem in load_tp_soft{,_fdpic} in arm.md in
GCC, but I've never found how to fix it yet...

Anyway, armv5 works almost fine with the fix for compiler_rt. I will
commit it soon if there's no objections.

Thanks,
rin