This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH 00/26] ARM improvements
On 02/27/2013 08:58 AM, Joseph S. Myers wrote:
> Could you please clarify how these patches have been tested?
As make check on a Cortex-A15 LE, both in arm and thumb mode.
> what testing has been done for big-endian (I think the string
> functions at least do need bit-endian testing - it should be possible to
> run string tests with userspace QEMU without needing BE hardware).
I haven't done that recently, but I can do that again.
> I'd typically expect builds to be done with CC containing any relevant
> options for this sort of thing, rather than CFLAGS.
Point. I'll give that a try in future.
> That also raises the question of dependencies between the patches. Given
> a patch series like this, each subset 1-N of the patches should generally
> leave the tree in a working state. But if a patch (say patch 6) makes
> changes to .S code for __thumb2__ that are only correct after that
> actually means the generated code is Thumb-2 (patch 12) that leaves a
> broken intermediate state (given a compiler that defaults to Thumb-2,
> whether because configured --with-mode=thumb or because of the options in
> $CC), meaning the changes can't quite go in the given order (patch 5 could
> define pc_ofs unconditionally to 8 in assembly code, for example, and only
> patch 12 change the value for Thumb-2 assembly).
I was attempting such an order, but I see what you mean about cpp conditionals
not matching up with the actual assembly mode.
As far as I can remember, pc_ofs is the only such example. The rest of the
changes -- I'm thinking of how pc is added to addresses and negative offset
addressing -- while conditioned on __thumb2__ still produce valid ARM insns.
r~