Subzero: Fix new issues after the LLVM 3.5 merge.

Subzero: Fix new issues after the LLVM 3.5 merge.

We need to link with -lpthread now.

The CALLTARGETS workaround in our lit tests can be removed, since llvm-objdump has gotten more accurate than before with respect to symbols.

The -stats and -rng-seed options need to be renamed to avoid conflicting with the LLVM options being brought in.

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

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-subzero.git;a=commit;h=332464279971e7d5e1deed9fecc54385532cd118

[Jim Stichnoth, 2014-11-24 05:36:43]

stichnot@chromium.org changed reviewers:
+ jvoung@chromium.org, kschimpf@google.com

[Karl, 2014-11-24 16:59:48]

While the CL looks good to me, I'm not quite sure if the fix to CALLTARGETS is
ok. Letting Jan check that.

[Jim Stichnoth, 2014-11-24 17:04:58]

On 2014/11/24 16:59:48, Karl wrote:
> While the CL looks good to me, I'm not quite sure if the fix to CALLTARGETS is
> ok. Letting Jan check that.

Agreed.  The lit tests actually work correctly when the CALLTARGETS tests are
not deleted, so this is basically cleaning up the TODOs that Jan left.

[jvoung (off chromium), 2014-11-24 17:24:00]

LGTM thanks

https://codereview.chromium.org/756543002/diff/1/Makefile.standalone
File Makefile.standalone (right):

https://codereview.chromium.org/756543002/diff/1/Makefile.standalone#newcode77
Makefile.standalone:77: `$(LLVM_BIN_PATH)/llvm-config --ldflags`
I think what happened with lpthread is that `llvm-config --ldflags` used to have
that, but now it's moved to `llvm-config --system-libs`

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
File tests_lit/llvm2ice_tests/fp.pnacl.ll (left):

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
tests_lit/llvm2ice_tests/fp.pnacl.ll:11: ; RUN:   | FileCheck
--check-prefix=CALLTARGETS %s
Just FYI, this might be in for some more churn.

LLVM r216983 actually removes the "--symbolize" flag =(

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140901/233448.html

I think that by printing relocations, the test can see the symbol, but that's
only if the call needs a relocation. I can see if this can be adjusted further
in another CL. Or perhaps we should use regular objdump instead of llvm-objdump.
The only thing then is if we run the tests on bots, the windows bot will need to
know the path of a binutils build as well.

[Jim Stichnoth, 2014-11-24 22:20:03]

https://codereview.chromium.org/756543002/diff/1/Makefile.standalone
File Makefile.standalone (right):

https://codereview.chromium.org/756543002/diff/1/Makefile.standalone#newcode77
Makefile.standalone:77: `$(LLVM_BIN_PATH)/llvm-config --ldflags`
On 2014/11/24 17:24:00, jvoung wrote:
> I think what happened with lpthread is that `llvm-config --ldflags` used to
have
> that, but now it's moved to `llvm-config --system-libs`

Cool, thanks.  I added --system-libs here.

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
File tests_lit/llvm2ice_tests/fp.pnacl.ll (left):

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
tests_lit/llvm2ice_tests/fp.pnacl.ll:11: ; RUN:   | FileCheck
--check-prefix=CALLTARGETS %s
On 2014/11/24 17:24:00, jvoung wrote:
> Just FYI, this might be in for some more churn.
> 
> LLVM r216983 actually removes the "--symbolize" flag =(
> 
>
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140901/233448.html
> 
> I think that by printing relocations, the test can see the symbol, but that's
> only if the call needs a relocation. I can see if this can be adjusted further
> in another CL. Or perhaps we should use regular objdump instead of
llvm-objdump.
> The only thing then is if we run the tests on bots, the windows bot will need
to
> know the path of a binutils build as well.

Hmm, that's a bit troubling.  Do you think I should add the CALLTARGETS tests
back?

Another thought is that we could switch over to GNU objdump whose outpt is
presumably far more stable?

[jvoung (off chromium), 2014-11-24 22:31:51]

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
File tests_lit/llvm2ice_tests/fp.pnacl.ll (left):

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
tests_lit/llvm2ice_tests/fp.pnacl.ll:11: ; RUN:   | FileCheck
--check-prefix=CALLTARGETS %s
On 2014/11/24 22:20:03, stichnot wrote:
> On 2014/11/24 17:24:00, jvoung wrote:
> > Just FYI, this might be in for some more churn.
> > 
> > LLVM r216983 actually removes the "--symbolize" flag =(
> > 
> >
>
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140901/233448.html
> > 
> > I think that by printing relocations, the test can see the symbol, but
that's
> > only if the call needs a relocation. I can see if this can be adjusted
further
> > in another CL. Or perhaps we should use regular objdump instead of
> llvm-objdump.
> > The only thing then is if we run the tests on bots, the windows bot will
need
> to
> > know the path of a binutils build as well.
> 
> Hmm, that's a bit troubling.  Do you think I should add the CALLTARGETS tests
> back?
> 
> Another thought is that we could switch over to GNU objdump whose outpt is
> presumably far more stable?


I'm thinking that switching to GNU objdump vs keeping CALLTARGETS would be
better. Otherwise we'll still depend on the .s text for these couple of tests?

[Jim Stichnoth, 2014-11-24 22:36:17]

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
File tests_lit/llvm2ice_tests/fp.pnacl.ll (left):

https://codereview.chromium.org/756543002/diff/1/tests_lit/llvm2ice_tests/fp....
tests_lit/llvm2ice_tests/fp.pnacl.ll:11: ; RUN:   | FileCheck
--check-prefix=CALLTARGETS %s
On 2014/11/24 22:31:51, jvoung wrote:
> I'm thinking that switching to GNU objdump vs keeping CALLTARGETS would be
> better. Otherwise we'll still depend on the .s text for these couple of tests?

OK.  I'll keep a mental TODO to switch to GNU objdump.  That would presumably
also help the situation in this CL where the output has further degraded from
e.g. [4] to [.bss].

[Jim Stichnoth, 2014-11-24 22:36:37]

Committed patchset #2 (id:20001) manually as
332464279971e7d5e1deed9fecc54385532cd118 (presubmit successful).