Inject gnueabihf environment into the effective clang triple for NaCl

Inject gnueabihf environment into the effective clang triple for NaCl

The effective clang triple is what the clang driver passes as the
-target flag for its cc1 jobs. Setting gnueabihf as the default environment
for nacl means that the the triple with that environment will end up as the
module's triple (instead of just "armv7-nacl") and the clang LLVM sides will
always agree on the defaults. This mostly doesn't matter except for things
like calls to runtime functions such as those in compiler-rt or libcxxabi,
where a mismatch was observed.

With this change the modules have the environment in the module's triple
and the calling convention is not explicitly overriden on every function
define and callsite as it was before.

R=jfb@chromium.org, jvoung@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=4018

Committed: 2394ea917dc67604cbda4945312f76e9b4f60943

[JF, 2015-01-21 04:07:58]

Do we also need to pass -float-abi=hard ?

Does that mean that we force ARM users into having gnueabihf? It seems unlikely
that they would want anything else (they'd have to build all the other libraries
themselves too), but IIUC that's currently impossible.

lgtm if the above are non-issues.

[jvoung (off chromium), 2015-01-21 16:36:23]

Otherwise LGTM

https://codereview.chromium.org/838933004/diff/1/lib/Driver/ToolChains.cpp
File lib/Driver/ToolChains.cpp (right):

https://codereview.chromium.org/838933004/diff/1/lib/Driver/ToolChains.cpp#ne...
lib/Driver/ToolChains.cpp:2533: const llvm::opt::ArgList &Args,
Can this just be ArgList (like the Darwin version of
ComputeEffectiveClangTriple) instead of llvm::opt::ArgList?

https://codereview.chromium.org/838933004/diff/1/lib/Driver/Tools.cpp
File lib/Driver/Tools.cpp (left):

https://codereview.chromium.org/838933004/diff/1/lib/Driver/Tools.cpp#oldcode632
lib/Driver/Tools.cpp:632: case llvm::Triple::NaCl: // @LOCALMOD
Seems like this localmod is no longer needed if the env is now gnueabihf?

[Derek Schuff, 2015-01-21 17:37:37]

> Do we also need to pass -float-abi=hard ?
No, the localmod Jan mentioned covers it (and the environment; see below).

> Does that mean that we force ARM users into having gnueabihf? It seems
unlikely
> that they would want anything else (they'd have to build all the other
libraries
> themselves too), but IIUC that's currently impossible.

I changed it to only inject the environment if there is not an environment
specified. That gets us a little further but doesn't quite get the default I
think. But people can still use flags to override things that the environment
implies (e.g. float ABI) and also specify calling conventions manually (which
they would probably have to do anyway since they'd need to use the AAPCS/EABI
calling conventions at least to call IRT code)

https://codereview.chromium.org/838933004/diff/1/lib/Driver/ToolChains.cpp
File lib/Driver/ToolChains.cpp (right):

https://codereview.chromium.org/838933004/diff/1/lib/Driver/ToolChains.cpp#ne...
lib/Driver/ToolChains.cpp:2533: const llvm::opt::ArgList &Args,
On 2015/01/21 16:36:22, jvoung wrote:
> Can this just be ArgList (like the Darwin version of
> ComputeEffectiveClangTriple) instead of llvm::opt::ArgList?

Done.

https://codereview.chromium.org/838933004/diff/1/lib/Driver/Tools.cpp
File lib/Driver/Tools.cpp (left):

https://codereview.chromium.org/838933004/diff/1/lib/Driver/Tools.cpp#oldcode632
lib/Driver/Tools.cpp:632: case llvm::Triple::NaCl: // @LOCALMOD
On 2015/01/21 16:36:23, jvoung wrote:
> Seems like this localmod is no longer needed if the env is now gnueabihf?

Unfortunately it can't be, because this function is also called by the assembler
tool, which doesn't use the effective clang triple.

[Derek Schuff, 2015-01-21 19:01:48]

Committed patchset #2 (id:20001) manually as
2394ea917dc67604cbda4945312f76e9b4f60943 (presubmit successful).