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
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: <libc-ports at sourceware dot org>
- Date: Wed, 27 Feb 2013 16:58:53 +0000
- Subject: Re: [PATCH 00/26] ARM improvements
- References: <1361934986-17018-1-git-send-email-rth@twiddle.net>
Could you please clarify how these patches have been tested? In
particular, 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).
> Patches 4-18 improve the ability to build libc as a thumb2 binary.
> In the end, almost all assembly is done in thumb2 mode if -mthumb
> is present in ASFLAGS. Its that last that's the sticky part: by
> default we copy only a couple of flags over from CFLAGS. I'm not
> sure why we're not passing them all to the assembler. So at the
> moment I'm just putting ASFLAGS on the make command-line to get
> what I want.
I'd typically expect builds to be done with CC containing any relevant
options for this sort of thing, rather than CFLAGS.
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).
--
Joseph S. Myers
joseph@codesourcery.com