Use -mtls-use-call in newlib build.

Use -mtls-use-call in newlib build.

This cleans up the configure/make invocation for building newlib
to remove bit rot and pointless duplication, and to use a cleaner
method to set build options.

The CROSSARCH=nacl mode was (nonobviously) never really being used,
and so had unintended divergence from the CROSSARCH=nacl64 mode.  I've
consolidated the newlib build commands to use consistent commands for
both modes without the unneeded mode test.  The -m32/-m64 flags given
are superfluous here and overridden by a later -m32 or -m64 that the
newlib configury/makefiles will add anyway.

Passing values for CFLAGS et al as configure arguments is the
preferred method.  It makes sure that they get saved properly in
config.status files and can't get lost by manual make runs or
automatic configure re-runs.  The newlib configury does not support
that correctly for CCASFLAGS, so using CCASFLAGS settings at all was
error-prone.  Instead, I put the assembly-specific -D option directly
into the CFLAGS_FOR_TARGET.  There it's used for both C and assembly
compilations, but it does no harm for the C cases.

I used the make variable NEWLIB_CFLAGS to avoid manual repetition of
the flags given to both CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET.
The CXXFLAGS_FOR_TARGET is almost certainly pointless for newlib,
which contains no C++.  But it does no harm to set it, and it should
be kept consistent with CFLAGS_FOR_TARGET without risk of bit rot due
to failure of manual parallel updates.

The shell commands to run configure and make were needlessly hairy
and made it quite unclear that they are doing something quite simple.
I made them just do the obvious thing instead.

I've verified empirically that the actual compiler options passed for
each file are no different after these cleanups except for the
addition of the option -D_I386MACH_ALLOW_HW_INTERRUPTS, and that the
.o files from the build did not change at all.

Finally, I did the actual point: adding -mtls-use-call to the options
for building newlib.  This is needed for the newlib and libstdc++
builds to be used in the integrated runtime blob.

BUG=http://code.google.com/p/nativeclient/issues/detail?id=1595
TEST= local builds of toolchain and then {small,medium,large}_tests using it

R=mseaborn@google.com,khim@google.com,pasko@google.com,eaeltsin@google.com

Committed: http://src.chromium.org/viewvc/native_client?view=rev&revision=4820

[Mark Seaborn, 2011-04-11 22:57:32]

LGTM with a nit.

http://codereview.chromium.org/6823058/diff/1/tools/Makefile
File tools/Makefile (right):

http://codereview.chromium.org/6823058/diff/1/tools/Makefile#newcode461
tools/Makefile:461: PATH=$(BUILDPATH); \
"&&" instead of ";"?  (This could fail if $(BUILDPATH) contains a space.)  If
you make this change, the next line should be indented by 2 for consistency.

Maybe "export PATH=..." instead of "PATH=..." - again, just in case.

[Mark Seaborn, 2011-04-11 23:01:31]

On 11 April 2011 15:57, <mseaborn@chromium.org> wrote:

> LGTM with a nit.
>

Thinking about this more -- you might want to put in a comment saying why we
use "-mtls-use-call" here:  i.e. because this will be linked into the IRT,
but it's suboptimal for user code.  Eventually we might rid the IRT of TLS,
or have two newlib builds (for IRT and for user code).

Also, "-mtls-use-call" will need to be added to libstdc++, but that can be a
separate change.

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[Roland McGrath, 2011-04-11 23:06:44]

Did all three.  PATH can never fail to be exported in reality, but did anyway.

[pasko-google - do not use, 2011-04-12 12:35:59]

LGTM

thanks for cleanup, Roland.  We had CROSSARCH=nacl working for newlib a while
ago, we used it to run GCC dejagnu testsuite.  But that has bit-rotten.  Having
the testsuite runnable on top of the multilib toolchain would be more useful. 
Looking forward to running it on buildbots some day.