[MIPS] Do not use pnacl-irt-link for MIPS target.

[MIPS] Do not use pnacl-irt-link for MIPS target.

Recent change ("Build the ARM core IRT using arm-flavored bitcode") broke the
build for MIPS.

"--pnacl-irt-link" should be used for ARM only.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=2275
TEST= build run_irt_thread_test


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

[Mark Seaborn, 2012-12-28 12:41:39]

This change seems reasonable to me.  However, I don't know why the flag was
added unconditionally or why it works for x86 but not MIPS.  Maybe Derek or Jan
should comment before this is committed?

[petarj, 2012-12-28 16:04:54]

On 2012/12/28 12:41:39, Mark Seaborn wrote:
> added unconditionally or why it works for x86 but not MIPS.

'bitcode' is set only for ARM and MIPS, see SConstruct, line 989

[jvoung (off chromium), 2012-12-28 17:21:15]

https://codereview.chromium.org/11691004/diff/1/SConstruct
File SConstruct (right):

https://codereview.chromium.org/11691004/diff/1/SConstruct#newcode3082
SConstruct:3082: nacl_irt_env.ClearBits('bitcode')
yeah -- also, arm and mips are the only ones that don't enforce that you use the
gcc toolchain, since chrome is already using the gcc toolchain for x86.

https://codereview.chromium.org/11691004/diff/1/SConstruct#newcode3127
SConstruct:3127: nacl_irt_env.Append(LINKFLAGS=['-Wl,--pnacl-irt-link'])
The reason we have --pnacl-irt-link, is that the IRT is built with a different
ABI from PNaCl's "le32" ABI.  It's built with the ARM hard float gnueabi ABI on
ARM, for compatibility with GCC.  Then we have the "shim" built by clang to
bridge the le32 ABI with the gcc one, since clang knows about both ABIs and has
the source-level type information to do the ABI matching.

In order to achieve that, the bitcode needs to be biased toward that ABI, so the
bitcode libraries that the IRT uses, like libstdc++, has to be
architecture-biased libraries (not stock le32 bitcode libraries).

Perhaps file an issue and link it to a TODO for ironing out the MIPS ABI.  If we
want compatibility with some future MIPS gcc NaCl port, then I suspect we will
want to do something similar with mips-biased bitcode.  

(1) actually change the IRT build to use the chosen mips abi (like the code on
line 3112).

(2) build biased libraries for mips so that --pnacl-irt-link works.

(3) modify clang a bit to be able to generate the shim that bridges the two
ABIs.


nit: indentation (4 spaces instead of 3?)

[Mark Seaborn, 2012-12-28 18:06:39]

https://codereview.chromium.org/11691004/diff/1/SConstruct
File SConstruct (right):

https://codereview.chromium.org/11691004/diff/1/SConstruct#newcode3127
SConstruct:3127: nacl_irt_env.Append(LINKFLAGS=['-Wl,--pnacl-irt-link'])
Fix indentation here, then LGTM.

petarj wrote:
> On 2012/12/28 12:41:39, Mark Seaborn wrote:
> > added unconditionally or why it works for x86 but not MIPS.
>
> 'bitcode' is set only for ARM and MIPS, see SConstruct, line 989

Ah yes, of course, that makes sense.

Actually, this is the relevant part (line 3081):

# For x86 systems we build the IRT using the nnacl TC even when
# the pnacl TC is used otherwise
if nacl_irt_env.Bit('target_x86_64') or nacl_irt_env.Bit('target_x86_32'):
  nacl_irt_env.ClearBits('bitcode')

[commit-bot: I haz the power, 2013-01-01 04:11:34]

CQ is trying da patch. Follow status at
https://nativeclient-status.appspot.com/cq/petarj@mips.com/11691004/14004

[commit-bot: I haz the power, 2013-01-01 05:41:07]

Change committed as 10523