This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 00/26] ARM improvements


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]