NonSFI mode: Enable compiling exception_test for NonSFI NaCl on ARM

NonSFI mode: Enable compiling exception_test for NonSFI NaCl on ARM

NonSFI newlib uses pnacl-clang toolchain for x86-32 and ARM architectures.
Try enabling inline assembly for those architectures with appropriate flags for tests.

Test will run if forced but will not pass.

TESTED=   ./scons -j20 --mode=dbg-host,nacl \
  bitcode=1 nonsfi_nacl=1 pnacl_generate_pexe=0 \
  platform=arm run_exception_test

 ./scons -j20 --mode=dbg-host,nacl_irt_test \
  bitcode=1 nonsfi_nacl=1 pnacl_generate_pexe=0 \
  use_newlib_nonsfi_loader=0 platform=arm run_exception_test
  # now fails with SIGSEGV in first test instead of not being able to build.

BUG= https://code.google.com/p/chromium/issues/detail?id=408879

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

[Junichi Uekawa, 2014-09-05 08:37:18]

https://codereview.chromium.org/544003002/diff/20001/tests/exception_test/nac...
File tests/exception_test/nacl.scons (right):

https://codereview.chromium.org/544003002/diff/20001/tests/exception_test/nac...
tests/exception_test/nacl.scons:9: if not env.AllowNonStableBitcode():
Now this goes a bit further.

/ssd/nacl2/native_client/toolchain/linux_x86/pnacl_newlib/bin/pnacl-translate
-arch x86-32-nonsfi --allow-llvm-bitcode-input --allow-llvm-bitcode-input
--allow-llvm-bitcode-input --allow-llvm-bitcode-input
--allow-llvm-bitcode-input\
 --allow-llvm-bitcode-input --allow-llvm-bitcode-input
--allow-llvm-bitcode-input
scons-out/nacl_irt_test-x86-32-pnacl-pexe-nonsfi-clang/obj/tests/exception_test/exception_test.nonfinal.pexe
-o scons-out/nacl_irt_test-x86-32-pnacl-p\
exe-nonsfi-clang/obj/tests/exception_test/exception_test.nexe                   
                                                                                
                                                                       
/ssd/nacl2/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: read-only segment has dynamic relocations

[Junichi Uekawa, 2014-09-09 12:23:58]

uekawa@chromium.org changed reviewers:
+ hamaji@chromium.org, hidehiko@chromium.org, mseaborn@chromium.org

[Junichi Uekawa, 2014-09-09 12:23:58]

ptal

https://codereview.chromium.org/544003002/diff/100001/SConstruct
File SConstruct (right):

https://codereview.chromium.org/544003002/diff/100001/SConstruct#newcode3027
SConstruct:3027: if env.Bit('bitcode'):
I am a little bit confused by how this part is constructed since the flags are
slightly different from what we're using in src/nonsfi/linux/nacl.scons

Not sure if I can merge the two sections and if that makes things easier to
maintain / read, and I don't claim to have understood what's happening here
quite yet.

https://codereview.chromium.org/544003002/diff/100001/tests/common/register_s...
File tests/common/register_set.h (right):

https://codereview.chromium.org/544003002/diff/100001/tests/common/register_s...
tests/common/register_set.h:243: "push $" #def_func "@got\n"  /* Fill out
prog_ctr with known value */ \
This works around having relocation in code, but wondering if this would break
others.

https://codereview.chromium.org/544003002/diff/100001/tests/exception_test/ex...
File tests/exception_test/exception_test.c (right):

https://codereview.chromium.org/544003002/diff/100001/tests/exception_test/ex...
tests/exception_test/exception_test.c:125: __attribute__((__used__))
inline assembly is something external in pexe, so code would look like it's
unused if only assembly is used.

[Junichi Uekawa, 2014-09-09 15:28:03]

https://codereview.chromium.org/544003002/diff/100001/tests/common/register_s...
File tests/common/register_set.h (right):

https://codereview.chromium.org/544003002/diff/100001/tests/common/register_s...
tests/common/register_set.h:243: "push $" #def_func "@got\n"  /* Fill out
prog_ctr with known value */ \
On 2014/09/09 12:23:58, Junichi Uekawa wrote:
> This works around having relocation in code, but wondering if this would break
> others.

Looking at try results of course it does, but then I don't really have a good
solution right now about how to be able to not use a absolute address.

This ends up giving me:
/ssd/nacl2/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: read-only segment has dynamic relocations

[Mark Seaborn, 2014-09-10 02:45:22]

I had a go at building exception_test for Non-SFI mode myself to debug this.

For background, bear in mind that there are a couple of ways of using the
Scons build and the PNaCl toolchain to build nexes containing assembly code
(like exception_test has):

 1) Invoking Scons with "pnacl_generate_pexe=0".  This enables mixed
bitcode/native linking.  Object files are built as bitcode by default (and
are translated as needed), but it's possible to link in native object files
too.  The Scons build has supported this for a long time -- it's the
original way to do hybrid builds using the PNaCl toolchain.

 2) Building non-ABI-stable pexes containing assembly code.  This is what
the Scons build currently does for non-IRT-using tests in Non-SFI mode
(when nonsfi_nacl=1).  This is set up in SConstruct via the special case
for "if nacl_env.Bit('nonsfi_nacl')" that sets 'nonstable_bitcode'
and '--pnacl-disable-abi-check'.  Maybe it was a bad idea for me to have
made this work differently from (1)?


(1) currently works for me, using SFI mode:

$ ./scons run_exception_test platform=arm bitcode=1 pnacl_generate_pexe=0
-j4

However, if I add "--mode=dbg-host,nacl,nacl_irt_test" to that (in order to
try running the IRT-using variant of the test, "run_exception_test_irt"),
then I get a cryptic traceback, which turns out to be a failure
in tests/pnacl_native_objects/nacl.scons.  It looks that nacl.scons file is
broken by pnacl_generate_pexe=0.  Presumably we don't currently test
IRT-using mode with pnacl_generate_pexe=0.  I haven't investigated this yet.

However, if I comment out "tests/pnacl_native_objects/nacl.scons" in
SConstruct, then this works too:

$ ./scons run_exception_test_irt platform=arm bitcode=1
pnacl_generate_pexe=0 -j4 --mode=dbg-host,nacl,nacl_irt_test

If I then try this in Non-SFI mode, then I get:

$ ./scons run_exception_test_irt platform=arm bitcode=1
pnacl_generate_pexe=0 -j4 --mode=dbg-host,nacl,nacl_irt_test nonsfi_nacl=1
use_newlib_nonsfi_loader=0
...
pnacl-ld:
scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test.o:
Incompatible object file (ARM != ARM_NONSFI)

It looks like I haven't synced to a NaCl revision that pulls in Hidehiko's
fix from r13708 yet.  I'll try this again after downloading the current
toolchain version...

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[Mark Seaborn, 2014-09-10 03:24:39]

On 9 September 2014 08:28, <uekawa@chromium.org> wrote:

>
> https://codereview.chromium.org/544003002/diff/100001/
> tests/common/register_set.h
> File tests/common/register_set.h (right):
>
> https://codereview.chromium.org/544003002/diff/100001/
> tests/common/register_set.h#newcode243
> tests/common/register_set.h:243: "push $" #def_func "@got\n"  /* Fill
> out prog_ctr with known value */ \
> On 2014/09/09 12:23:58, Junichi Uekawa wrote:
>
>> This works around having relocation in code, but wondering if this
>>
> would break
>
>> others.
>>
>
> Looking at try results of course it does, but then I don't really have a
> good solution right now about how to be able to not use a absolute
> address.
>
> This ends up giving me:
> /ssd/nacl2/native_client/toolchain/linux_x86/pnacl_
> newlib/host_x86_32/bin/le32-nacl-ld.gold:
> error: read-only segment has dynamic relocations


Making the x86-32 assembly code in register_set.h PIC-friendly is a little
more complex than that.

You'll need to change it to something like this:

"push $0\n"  /* Leave space for flags */ \
"push $0\n"  /* Leave space for prog_ctr */ \
"push %edi\n" \
"push %esi\n" \
...
/* Save flags. */ \
SAVE_X86_FLAGS_INTO_REG("%eax") \
"movl %eax, 0x24(%esp)\n" \
/* Fill out prog_ctr with known value. */
"call 0f\n" \
"0: popl %eax\n" \
"1: addl $_GLOBAL_OFFSET_TABLE_ + (1b - 0b), %eax\n" \
"movl " #def_func "@GOT(%eax), %eax\n" \
"movl %eax, 0x20(%esp)\n" \

Actually, a shorter and simpler version would be:

/* Fill out prog_ctr with known value. */
"call 0f\n" \
"0: popl %eax\n" \
"addl $" #def_func " - 0b, %eax\n" \
"movl %eax, 0x20(%esp)\n" \

BTW, this is based on the code that compilers will generate for accessing
global variables on x86-32 when using "-fPIC".

For comparison, try compiling a function like the following with "gcc -m32
-march=i386 -fPIC foo.c -S -o - -O1":

int var;
int getter(void) { return &var; }

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[native-client-reviews_googlegroups.com, 2014-09-10 06:40:15]

Now that I had toolchain synced I tried looking at using
pnacl_generate_pexe, it seems like there's things that need fixing further.

 1) ./scons -j20 --mode=dbg-host,nacl_irt_test bitcode=1 nonsfi_nacl=1
 pnacl_generate_pexe=0 run_exception_test_irt  use_newlib_nonsfi_loader=0
platform=x86-32
Needs fixing up AllowInlineAssembly because there is a check against
pnacl-clang inline assembly on x86-32.
Other than that it looks as if things are compiling... except that fails
with this error message for me. (It's relatively annoying that this error
message doesn't tell me which symbol is causing this message).

________Linking
scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test_x86-32.nexe

/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: read-only segment has dynamic relocations




 2) ./scons -j20 --mode=dbg-host,nacl_irt_test bitcode=1 nonsfi_nacl=1
 pnacl_generate_pexe=0 run_exception_test_irt  use_newlib_nonsfi_loader=0
platform=arm
I think there's ABI issues here.


/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: scons-out/nacl_irt_test-arm-pnacl-non\
sfi-clang/obj/tests/exception_test/exception_test.o: requires unsupported
dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: scons-out/nacl-arm-pnacl-nonsfi-clang\
/lib/libtest_common.a(register_set.o): requires unsupported dynamic reloc
R_ARM_MOVW_ABS_NC; recompile with -fPIC
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: scons-out/nacl_irt_test-arm-pnacl-non\
sfi-clang/obj/tests/exception_test/exception_test.o uses VFP register
arguments, output does not
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: scons-out/nacl-arm-pnacl-nonsfi-clang\
/lib/libtest_common.a(register_set.o) uses VFP register arguments, output
does not



2014-09-10 11:45 GMT+09:00 Mark Seaborn <mseaborn@chromium.org>:

> I had a go at building exception_test for Non-SFI mode myself to debug
> this.
>
> For background, bear in mind that there are a couple of ways of using the
> Scons build and the PNaCl toolchain to build nexes containing assembly code
> (like exception_test has):
>
>  1) Invoking Scons with "pnacl_generate_pexe=0".  This enables mixed
> bitcode/native linking.  Object files are built as bitcode by default (and
> are translated as needed), but it's possible to link in native object files
> too.  The Scons build has supported this for a long time -- it's the
> original way to do hybrid builds using the PNaCl toolchain.
>
>  2) Building non-ABI-stable pexes containing assembly code.  This is what
> the Scons build currently does for non-IRT-using tests in Non-SFI mode
> (when nonsfi_nacl=1).  This is set up in SConstruct via the special case
> for "if nacl_env.Bit('nonsfi_nacl')" that sets 'nonstable_bitcode'
> and '--pnacl-disable-abi-check'.  Maybe it was a bad idea for me to have
> made this work differently from (1)?
>
>
> (1) currently works for me, using SFI mode:
>
> $ ./scons run_exception_test platform=arm bitcode=1 pnacl_generate_pexe=0
> -j4
>
> However, if I add "--mode=dbg-host,nacl,nacl_irt_test" to that (in order
> to try running the IRT-using variant of the test,
> "run_exception_test_irt"), then I get a cryptic traceback, which turns out
> to be a failure in tests/pnacl_native_objects/nacl.scons.  It looks that
> nacl.scons file is broken by pnacl_generate_pexe=0.  Presumably we don't
> currently test IRT-using mode with pnacl_generate_pexe=0.  I haven't
> investigated this yet.
>
> However, if I comment out "tests/pnacl_native_objects/nacl.scons" in
> SConstruct, then this works too:
>
> $ ./scons run_exception_test_irt platform=arm bitcode=1
> pnacl_generate_pexe=0 -j4 --mode=dbg-host,nacl,nacl_irt_test
>
> If I then try this in Non-SFI mode, then I get:
>
> $ ./scons run_exception_test_irt platform=arm bitcode=1
> pnacl_generate_pexe=0 -j4 --mode=dbg-host,nacl,nacl_irt_test nonsfi_nacl=1
> use_newlib_nonsfi_loader=0
> ...
> pnacl-ld:
>
scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test.o:
> Incompatible object file (ARM != ARM_NONSFI)
>
> It looks like I haven't synced to a NaCl revision that pulls in Hidehiko's
> fix from r13708 yet.  I'll try this again after downloading the current
> toolchain version...
>
> Cheers,
> Mark
>
>


-- 
Junichi Uekawa
Google

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[Mark Seaborn, 2014-09-10 19:59:49]

On 9 September 2014 23:39, Junichi Uekawa (上川純一) <uekawa@google.com> wrote:

> Now that I had toolchain synced I tried looking at using
> pnacl_generate_pexe, it seems like there's things that need fixing further.
>
>  1) ./scons -j20 --mode=dbg-host,nacl_irt_test bitcode=1 nonsfi_nacl=1
>  pnacl_generate_pexe=0 run_exception_test_irt  use_newlib_nonsfi_loader=0
> platform=x86-32
> Needs fixing up AllowInlineAssembly because there is a check against
> pnacl-clang inline assembly on x86-32.
> Other than that it looks as if things are compiling... except that fails
> with this error message for me. (It's relatively annoying that this error
> message doesn't tell me which symbol is causing this message).
>
> ________Linking
>
scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test_x86-32.nexe
>
>
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
> error: read-only segment has dynamic relocations
>

I looked at the command that is generating exception_test.o:  pnacl-clang
is being invoked with "-arch x86-32".  So it looks
like site_scons/site_tools/naclsdk.py needs to be fixed to pass the correct
"-arch" flag when doing direct-to-native compiling (see PNaClForceNative()).

This means exception_test.o was getting compiled without "-fPIC".  ("-arch
x86-32-nonsfi" adds -fPIC automatically.)  That manifests itself as the
linker error above where the linker complains about TEXTRELs.  If you
disassemble exception_test.o with "objdump -dr", you'll see it's getting
compiled with NaCl SFI sandboxing, which we don't want.



>  2) ./scons -j20 --mode=dbg-host,nacl_irt_test bitcode=1 nonsfi_nacl=1
>  pnacl_generate_pexe=0 run_exception_test_irt  use_newlib_nonsfi_loader=0
> platform=arm
> I think there's ABI issues here.
>
>
>
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
> error: scons-out/nacl_irt_test-arm-pnacl-non\
> sfi-clang/obj/tests/exception_test/exception_test.o: requires unsupported
> dynamic reloc R_ARM_MOVW_ABS_NC; recompile with -fPIC
>
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
> error: scons-out/nacl-arm-pnacl-nonsfi-clang\
> /lib/libtest_common.a(register_set.o): requires unsupported dynamic reloc
> R_ARM_MOVW_ABS_NC; recompile with -fPIC
>

This is the same problem as above:  invoking pnacl-clang with "-arch arm"
instead of "-arch arm-nonsfi", so that "-fPIC" is not being used.



>
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
> error: scons-out/nacl_irt_test-arm-pnacl-non\
> sfi-clang/obj/tests/exception_test/exception_test.o uses VFP register
> arguments, output does not
>
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
> error: scons-out/nacl-arm-pnacl-nonsfi-clang\
> /lib/libtest_common.a(register_set.o) uses VFP register arguments, output
> does not
>

I think this is caused by a combination of:

 1) Mixing code compiled with "-arch arm" and "-arch arm-nonsfi" (as
above), and
 2) This bug: https://code.google.com/p/nativeclient/issues/detail?id=3869

While (2) needs to get fixed eventually, building exception_test doesn't
depend on it.  So if you just fix (1), (2) won't bite.

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[Mark Seaborn, 2014-09-10 20:01:42]

On 9 September 2014 20:24, Mark Seaborn <mseaborn@chromium.org> wrote:

> On 9 September 2014 08:28, <uekawa@chromium.org> wrote:
>
>>
>> https://codereview.chromium.org/544003002/diff/100001/
>> tests/common/register_set.h
>> File tests/common/register_set.h (right):
>>
>> https://codereview.chromium.org/544003002/diff/100001/
>> tests/common/register_set.h#newcode243
>> tests/common/register_set.h:243: "push $" #def_func "@got\n"  /* Fill
>> out prog_ctr with known value */ \
>> On 2014/09/09 12:23:58, Junichi Uekawa wrote:
>>
>>> This works around having relocation in code, but wondering if this
>>>
>> would break
>>
>>> others.
>>>
>>
>> Looking at try results of course it does, but then I don't really have a
>> good solution right now about how to be able to not use a absolute
>> address.
>>
>> This ends up giving me:
>> /ssd/nacl2/native_client/toolchain/linux_x86/pnacl_
>> newlib/host_x86_32/bin/le32-nacl-ld.gold:
>> error: read-only segment has dynamic relocations
>
>
> Making the x86-32 assembly code in register_set.h PIC-friendly is a little
> more complex than that.
>
> You'll need to change it to something like this:
>
> "push $0\n"  /* Leave space for flags */ \
> "push $0\n"  /* Leave space for prog_ctr */ \
> "push %edi\n" \
> "push %esi\n" \
> ...
> /* Save flags. */ \
> SAVE_X86_FLAGS_INTO_REG("%eax") \
> "movl %eax, 0x24(%esp)\n" \
> /* Fill out prog_ctr with known value. */
> "call 0f\n" \
> "0: popl %eax\n" \
> "1: addl $_GLOBAL_OFFSET_TABLE_ + (1b - 0b), %eax\n" \
> "movl " #def_func "@GOT(%eax), %eax\n" \
> "movl %eax, 0x20(%esp)\n" \
>
> Actually, a shorter and simpler version would be:
>
> /* Fill out prog_ctr with known value. */
> "call 0f\n" \
> "0: popl %eax\n" \
> "addl $" #def_func " - 0b, %eax\n" \
> "movl %eax, 0x20(%esp)\n" \
>

Can you perhaps send me a standalone change to register_set.h for the above?

Since it looks like getting exception_test to build for Non-SFI Mode will
be a bit of a yak-shave, we might as well get some of the dependencies
committed. :-)

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[native-client-reviews_googlegroups.com, 2014-09-11 01:04:42]

sounds good to me, ley me try doing that.

2014-09-11 5:01 GMT+09:00 Mark Seaborn <mseaborn@chromium.org>:

> On 9 September 2014 20:24, Mark Seaborn <mseaborn@chromium.org> wrote:
>
>> On 9 September 2014 08:28, <uekawa@chromium.org> wrote:
>>
>>>
>>> https://codereview.chromium.org/544003002/diff/100001/
>>> tests/common/register_set.h
>>> File tests/common/register_set.h (right):
>>>
>>> https://codereview.chromium.org/544003002/diff/100001/
>>> tests/common/register_set.h#newcode243
>>> tests/common/register_set.h:243: "push $" #def_func "@got\n"  /* Fill
>>> out prog_ctr with known value */ \
>>> On 2014/09/09 12:23:58, Junichi Uekawa wrote:
>>>
>>>> This works around having relocation in code, but wondering if this
>>>>
>>> would break
>>>
>>>> others.
>>>>
>>>
>>> Looking at try results of course it does, but then I don't really have a
>>> good solution right now about how to be able to not use a absolute
>>> address.
>>>
>>> This ends up giving me:
>>> /ssd/nacl2/native_client/toolchain/linux_x86/pnacl_
>>> newlib/host_x86_32/bin/le32-nacl-ld.gold:
>>> error: read-only segment has dynamic relocations
>>
>>
>> Making the x86-32 assembly code in register_set.h PIC-friendly is a
>> little more complex than that.
>>
>> You'll need to change it to something like this:
>>
>> "push $0\n"  /* Leave space for flags */ \
>> "push $0\n"  /* Leave space for prog_ctr */ \
>> "push %edi\n" \
>> "push %esi\n" \
>> ...
>> /* Save flags. */ \
>> SAVE_X86_FLAGS_INTO_REG("%eax") \
>> "movl %eax, 0x24(%esp)\n" \
>> /* Fill out prog_ctr with known value. */
>> "call 0f\n" \
>> "0: popl %eax\n" \
>> "1: addl $_GLOBAL_OFFSET_TABLE_ + (1b - 0b), %eax\n" \
>> "movl " #def_func "@GOT(%eax), %eax\n" \
>> "movl %eax, 0x20(%esp)\n" \
>>
>> Actually, a shorter and simpler version would be:
>>
>> /* Fill out prog_ctr with known value. */
>> "call 0f\n" \
>> "0: popl %eax\n" \
>> "addl $" #def_func " - 0b, %eax\n" \
>> "movl %eax, 0x20(%esp)\n" \
>>
>
> Can you perhaps send me a standalone change to register_set.h for the
> above?
>
> Since it looks like getting exception_test to build for Non-SFI Mode will
> be a bit of a yak-shave, we might as well get some of the dependencies
> committed. :-)
>
> Cheers,
> Mark
>
>


-- 
Junichi Uekawa
Google

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[native-client-reviews_googlegroups.com, 2014-09-12 16:39:19]

So I fixed (1) to get -arch arm-nonsfi, and the remaining issue seems to be
that at link time for arm
(x86-32 now links and runs), wip patch at
https://codereview.chromium.org/562853003

There are two error messages that worry me:

/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: unrecognized output format elf32-littlearm

and

scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test.o:
error: undefined reference to '__aeabi_read_tp'



/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/bin/pnacl-clang++
-arch arm-nonsfi --pnacl-allow-native --pnacl-allow-translate
-Bscons-out/nacl-arm-pnacl-nonsfi-clang/lib/
-Wl,-rpath-link,scons-out/nacl-arm-pnacl-nonsfi-clang/lib
-Wl,-rpath-link,toolchain/linux_x86/pnacl_newlib/lib
-Wl,-rpath-link,scons-out/nacl-arm-pnacl-nonsfi-clang/lib -O3 -static
scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test.o
-Lscons-out/nacl-arm-pnacl-nonsfi-clang/lib
-Ltoolchain/linux_x86/pnacl_newlib/lib
-Lscons-out/nacl-arm-pnacl-nonsfi-clang/lib -lpthread -lpthread
-ltestrunner -lnacl_exception -lnacl -ltest_common -o
scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test_arm.nexe
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: unrecognized output format elf32-littlearm
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples:
'armv4t--nacl' and 'le32-unknown-nacl'
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples:
'armv4t--nacl' and 'le32-unknown-nacl'
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples:
'armv4t--nacl' and 'le32-unknown-nacl'
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples:
'armv4t--nacl' and 'le32-unknown-nacl'
WARNING: Linking two modules of different data layouts!
WARNING: Linking two modules of different target triples:
'armv4t--nacl' and 'le32-unknown-nacl'
scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test.o:
error: undefined reference to '__aeabi_read_tp'
scons: ***
[scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test_arm.nexe]
Error 1
scons: building terminated because of errors.





2014-09-11 10:04 GMT+09:00 Junichi Uekawa (上川純一) <uekawa@google.com>:

> sounds good to me, ley me try doing that.
>
> 2014-09-11 5:01 GMT+09:00 Mark Seaborn <mseaborn@chromium.org>:
>
>> On 9 September 2014 20:24, Mark Seaborn <mseaborn@chromium.org> wrote:
>>
>>> On 9 September 2014 08:28, <uekawa@chromium.org> wrote:
>>>
>>>>
>>>> https://codereview.chromium.org/544003002/diff/100001/
>>>> tests/common/register_set.h
>>>> File tests/common/register_set.h (right):
>>>>
>>>> https://codereview.chromium.org/544003002/diff/100001/
>>>> tests/common/register_set.h#newcode243
>>>> tests/common/register_set.h:243: "push $" #def_func "@got\n"  /* Fill
>>>> out prog_ctr with known value */ \
>>>> On 2014/09/09 12:23:58, Junichi Uekawa wrote:
>>>>
>>>>> This works around having relocation in code, but wondering if this
>>>>>
>>>> would break
>>>>
>>>>> others.
>>>>>
>>>>
>>>> Looking at try results of course it does, but then I don't really have a
>>>> good solution right now about how to be able to not use a absolute
>>>> address.
>>>>
>>>> This ends up giving me:
>>>> /ssd/nacl2/native_client/toolchain/linux_x86/pnacl_
>>>> newlib/host_x86_32/bin/le32-nacl-ld.gold:
>>>> error: read-only segment has dynamic relocations
>>>
>>>
>>> Making the x86-32 assembly code in register_set.h PIC-friendly is a
>>> little more complex than that.
>>>
>>> You'll need to change it to something like this:
>>>
>>> "push $0\n"  /* Leave space for flags */ \
>>> "push $0\n"  /* Leave space for prog_ctr */ \
>>> "push %edi\n" \
>>> "push %esi\n" \
>>> ...
>>> /* Save flags. */ \
>>> SAVE_X86_FLAGS_INTO_REG("%eax") \
>>> "movl %eax, 0x24(%esp)\n" \
>>> /* Fill out prog_ctr with known value. */
>>> "call 0f\n" \
>>> "0: popl %eax\n" \
>>> "1: addl $_GLOBAL_OFFSET_TABLE_ + (1b - 0b), %eax\n" \
>>> "movl " #def_func "@GOT(%eax), %eax\n" \
>>> "movl %eax, 0x20(%esp)\n" \
>>>
>>> Actually, a shorter and simpler version would be:
>>>
>>> /* Fill out prog_ctr with known value. */
>>> "call 0f\n" \
>>> "0: popl %eax\n" \
>>> "addl $" #def_func " - 0b, %eax\n" \
>>> "movl %eax, 0x20(%esp)\n" \
>>>
>>
>> Can you perhaps send me a standalone change to register_set.h for the
>> above?
>>
>> Since it looks like getting exception_test to build for Non-SFI Mode will
>> be a bit of a yak-shave, we might as well get some of the dependencies
>> committed. :-)
>>
>> Cheers,
>> Mark
>>
>>
>
>
> --
> Junichi Uekawa
> Google
>



-- 
Junichi Uekawa
Google

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[Mark Seaborn, 2014-09-13 01:06:03]

On 12 September 2014 09:38, Junichi Uekawa (上川純一) <uekawa@google.com> wrote:

> So I fixed (1) to get -arch arm-nonsfi, and the remaining issue seems to
> be that at link time for arm
> (x86-32 now links and runs), wip patch at
> https://codereview.chromium.org/562853003
>
> There are two error messages that worry me:
>
>
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
error: unrecognized output format elf32-littlearm
>
> and
>
>
scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test.o:
error: undefined reference to '__aeabi_read_tp'
>
> I tried this locally and could reproduce that error.

I think you're running into the same problem that Derek encountered with
references to libgcc in direct-to-native x86-32 builds, which he fixed in
https://src.chromium.org/viewvc/native_client?view=rev&revision=13602.

__aeabi_read_tp is defined in libcrt_platform.a (by
pnacl/support/pnacl_irt.c).

Currently, mixed linking (bitcode + native objects) happens in three steps,
as described in https://codereview.chromium.org/454593002:

 * link #1 (bitcode + native) -- currently omits libcrt_platform.  This
step determines what bitcode to translate.
 * translate any bitcode to native code
 * link #2 (native-only) -- includes libcrt_platform

exception_test.o refers to __aeabi_read_tp, but libcrt_platform.a isn't
included in the library list of link #1.  The fix would be to add it to
link #1.

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[Junichi Uekawa, 2014-09-16 11:00:19]

On 2014/09/13 01:06:03, Mark Seaborn wrote:
> On 12 September 2014 09:38, Junichi Uekawa (上川純一) <mailto:uekawa@google.com>
wrote:
> 
> > So I fixed (1) to get -arch arm-nonsfi, and the remaining issue seems to
> > be that at link time for arm
> > (x86-32 now links and runs), wip patch at
> > https://codereview.chromium.org/562853003
> >
> > There are two error messages that worry me:
> >
> >
>
/ssd/nacl1/native_client/toolchain/linux_x86/pnacl_newlib/host_x86_32/bin/le32-nacl-ld.gold:
> error: unrecognized output format elf32-littlearm
> >
> > and
> >
> >
>
scons-out/nacl_irt_test-arm-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test.o:
> error: undefined reference to '__aeabi_read_tp'
> >
> > I tried this locally and could reproduce that error.
> 
> I think you're running into the same problem that Derek encountered with
> references to libgcc in direct-to-native x86-32 builds, which he fixed in
> https://src.chromium.org/viewvc/native_client?view=rev&revision=13602.
> 
> __aeabi_read_tp is defined in libcrt_platform.a (by
> pnacl/support/pnacl_irt.c).
> 
> Currently, mixed linking (bitcode + native objects) happens in three steps,
> as described in https://codereview.chromium.org/454593002:
> 
>  * link #1 (bitcode + native) -- currently omits libcrt_platform.  This
> step determines what bitcode to translate.
>  * translate any bitcode to native code
>  * link #2 (native-only) -- includes libcrt_platform
> 
> exception_test.o refers to __aeabi_read_tp, but libcrt_platform.a isn't
> included in the library list of link #1.  The fix would be to add it to
> link #1.
> 

Okay, so now I have things linking.

How does a change to pnacl-driver.py get propagated ? 
Filed a bug in case it's easier that way.
https://code.google.com/p/nativeclient/issues/detail?id=3951




> Cheers,
> Mark
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:native-client-reviews+unsubscribe@googlegroups.com.
> To post to this group, send email to
mailto:native-client-reviews@googlegroups.com.
> Visit this group at http://groups.google.com/group/native-client-reviews.
> For more options, visit https://groups.google.com/d/optout.

[Junichi Uekawa, 2014-09-17 09:19:36]

I've split out some changes and sent them out as:
https://codereview.chromium.org/546043004/
https://codereview.chromium.org/581463004/

This change is pending review/submit of these changes.

[Junichi Uekawa, 2014-09-19 03:50:48]

On 2014/09/17 09:19:36, Junichi Uekawa wrote:
> I've split out some changes and sent them out as:
> https://codereview.chromium.org/546043004/
> https://codereview.chromium.org/581463004/
> 
> This change is pending review/submit of these changes.

So now I've revisited with those changes, rebased and resynced and re-ran the
tests.

Maybe I wasn't looking at this before but I get a new error now:

[ RUN      ] pnacl_newlib.run_exception_test_irt                                
                                               
scons-out/dbg-linux-x86-32/staging/nonsfi_loader
scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/tests/exception_test/exc\
eption_test_x86-32.nexe                                                         
                                               
                                                                                
                                               
ERROR: Command returned exit status -4 (0xfffffffc) but did not output an
intended_exit_status line to stderr - did it exit too\
 early?                                                                         
                                               


This seems to be crashing at 
native_client/pnacl/support/relocate.c: apply_relocations

which checks for R_386_RELATIVE, and otherwise calls unhandled_relocation() and
crashes with ud2.

I am guessing this happened since -lcrt_platform.

[Junichi Uekawa, 2014-09-19 07:20:08]

On 2014/09/19 03:50:48, Junichi Uekawa wrote:
> On 2014/09/17 09:19:36, Junichi Uekawa wrote:
> > I've split out some changes and sent them out as:
> > https://codereview.chromium.org/546043004/
> > https://codereview.chromium.org/581463004/
> > 
> > This change is pending review/submit of these changes.
> 
> So now I've revisited with those changes, rebased and resynced and re-ran the
> tests.
> 
> Maybe I wasn't looking at this before but I get a new error now:
> 
> [ RUN      ] pnacl_newlib.run_exception_test_irt                              
 
>                                                
> scons-out/dbg-linux-x86-32/staging/nonsfi_loader
>
scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/tests/exception_test/exc\
> eption_test_x86-32.nexe                                                       
 
>                                                
>                                                                               
 
>                                                
> ERROR: Command returned exit status -4 (0xfffffffc) but did not output an
> intended_exit_status line to stderr - did it exit too\
>  early?                                                                       
 
>                                                
> 
> 
> This seems to be crashing at 
> native_client/pnacl/support/relocate.c: apply_relocations
> 
> which checks for R_386_RELATIVE, and otherwise calls unhandled_relocation()
and
> crashes with ud2.
> 
> I am guessing this happened since -lcrt_platform.

There's bunch of TLS-related symbols on x86-32.

$ objdump -R 
scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/tests/exception_test/exception_test_x86-32.nexe
  .
  .
  .
00011bd8 R_386_GLOB_DAT    __tls_template_tdata_end
00011bd4 R_386_GLOB_DAT    __tls_template_start
00011bdc R_386_GLOB_DAT    __tls_template_end
00011bd0 R_386_GLOB_DAT    __tls_template_alignment
00011bc4 R_386_GLOB_DAT    __nacl_main
00011bcc R_386_GLOB_DAT    __ehdr_start
00011c0c R_386_TLS_TPOFF   _impure_ptr

[Mark Seaborn, 2014-09-24 03:00:10]

On 19 September 2014 00:20, <uekawa@chromium.org> wrote:
>
> There's bunch of TLS-related symbols on x86-32.
>
> $ objdump -R
> scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/
> tests/exception_test/exception_test_x86-32.nexe
>   .
>   .
>   .
> 00011bd8 R_386_GLOB_DAT    __tls_template_tdata_end
> 00011bd4 R_386_GLOB_DAT    __tls_template_start
> 00011bdc R_386_GLOB_DAT    __tls_template_end
> 00011bd0 R_386_GLOB_DAT    __tls_template_alignment
> 00011bc4 R_386_GLOB_DAT    __nacl_main
> 00011bcc R_386_GLOB_DAT    __ehdr_start
> 00011c0c R_386_TLS_TPOFF   _impure_ptr


Hmm.  I investigated this a bit, and I see what is going on.

Let's back up a bit.  Bear in mind that exception_test is built using a
mode that hasn't been tested so far.  It is built with
"--pnacl-allow-translate" + "--pnacl-allow-native" + "-arch x86-32-nonsfi"
-- which Hidehiko has already been using for building nacl_helper_nonsfi.
However, it hasn't been tested for building nexes that follow the
x86-32-nonsfi ABI, and so use IRT interfaces, etc.  (nacl_helper_nonsfi
itself, as an executable, doesn't have to follow the x86-32-nonsfi ABI --
it makes Linux syscalls directly.)

So first it would be good to check a more minimal example than
exception_test, to check whether this mode of the toolchain can
successfully produce working IRT-using nexes.

This more minimal test shows that this mode doesn't work yet:

$ cat hellow.c
#include <stdio.h>
int main() {
  printf("Hello, world!\n");
  return 0;
}
$ pnacl-clang --pnacl-allow-translate hellow.c -arch x86-32-nonsfi -c
$ pnacl-clang --pnacl-allow-native hellow.o -arch x86-32-nonsfi -o
hellow.nexe
$
~/devel/nacl-git3/native_client/scons-out/nacl-x86-32-pnacl-pexe-nonsfi-clang/staging/nonsfi_loader.nexe
hellow.nexe
Illegal instruction (core dumped)

GDB shows that this hits the same unhandled_relocation() failure that you
hit with exception_test.

You're running into two problems, for the two relocation types you're
seeing above (R_386_GLOB_DAT and R_386_TLS_TPOFF):

 * The GLOB_DAT problem is caused by weak symbols, and would be fairly easy
to fix (or at least work around).
 * The TPS_TPOFF problem is harder to fix, for IRT-using executables.

(I can go into more of the details later.)

I would suggest that you try getting the non-IRT-using version of
exception_test to build first, since the non-IRT-using case is what works
more readily when using "--pnacl-allow-translate".  That is, try
"run_exception_test" rather than "run_exception_test_irt".

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[native-client-reviews_googlegroups.com, 2014-09-24 05:37:45]

Hmm... run_exception_test also fails, so I've tried to understand what's
going on. I took a look at run_hello_world_test because that seems to be
much simpler to tackle and fails with same error message as
run_exception_test.

./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32

Compiles and runs fine.

./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32 nonsfi_nacl=1

Does not compile, because gcc doesn't like -target=

./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32 nonsfi_nacl=1 bitcode=1

Compiles and runs fine.

./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32 nonsfi_nacl=1 bitcode=1 pnacl_generate_pexe=0

Fails to run, with "exception: [Errno 2] No such file or directory"

This message seems to be coming from INTERP=/usr/lib/libc.so.1 which
doesn't exist but don't really know where it comes from.




2014-09-24 11:59 GMT+09:00 Mark Seaborn <mseaborn@chromium.org>:

> On 19 September 2014 00:20, <uekawa@chromium.org> wrote:
>>
>> There's bunch of TLS-related symbols on x86-32.
>>
>> $ objdump -R
>> scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/
>> tests/exception_test/exception_test_x86-32.nexe
>>   .
>>   .
>>   .
>> 00011bd8 R_386_GLOB_DAT    __tls_template_tdata_end
>> 00011bd4 R_386_GLOB_DAT    __tls_template_start
>> 00011bdc R_386_GLOB_DAT    __tls_template_end
>> 00011bd0 R_386_GLOB_DAT    __tls_template_alignment
>> 00011bc4 R_386_GLOB_DAT    __nacl_main
>> 00011bcc R_386_GLOB_DAT    __ehdr_start
>> 00011c0c R_386_TLS_TPOFF   _impure_ptr
>
>
> Hmm.  I investigated this a bit, and I see what is going on.
>
> Let's back up a bit.  Bear in mind that exception_test is built using a
> mode that hasn't been tested so far.  It is built with
> "--pnacl-allow-translate" + "--pnacl-allow-native" + "-arch x86-32-nonsfi"
> -- which Hidehiko has already been using for building nacl_helper_nonsfi.
> However, it hasn't been tested for building nexes that follow the
> x86-32-nonsfi ABI, and so use IRT interfaces, etc.  (nacl_helper_nonsfi
> itself, as an executable, doesn't have to follow the x86-32-nonsfi ABI --
> it makes Linux syscalls directly.)
>
> So first it would be good to check a more minimal example than
> exception_test, to check whether this mode of the toolchain can
> successfully produce working IRT-using nexes.
>
> This more minimal test shows that this mode doesn't work yet:
>
> $ cat hellow.c
> #include <stdio.h>
> int main() {
>   printf("Hello, world!\n");
>   return 0;
> }
> $ pnacl-clang --pnacl-allow-translate hellow.c -arch x86-32-nonsfi -c
> $ pnacl-clang --pnacl-allow-native hellow.o -arch x86-32-nonsfi -o
> hellow.nexe
> $
>
~/devel/nacl-git3/native_client/scons-out/nacl-x86-32-pnacl-pexe-nonsfi-clang/staging/nonsfi_loader.nexe
> hellow.nexe
> Illegal instruction (core dumped)
>
> GDB shows that this hits the same unhandled_relocation() failure that you
> hit with exception_test.
>
> You're running into two problems, for the two relocation types you're
> seeing above (R_386_GLOB_DAT and R_386_TLS_TPOFF):
>
>  * The GLOB_DAT problem is caused by weak symbols, and would be fairly
> easy to fix (or at least work around).
>  * The TPS_TPOFF problem is harder to fix, for IRT-using executables.
>
> (I can go into more of the details later.)
>
> I would suggest that you try getting the non-IRT-using version of
> exception_test to build first, since the non-IRT-using case is what works
> more readily when using "--pnacl-allow-translate".  That is, try
> "run_exception_test" rather than "run_exception_test_irt".
>
> Cheers,
> Mark
>
>


-- 
Junichi Uekawa
Google

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[native-client-reviews_googlegroups.com, 2014-09-24 06:21:56]

https://src.chromium.org/viewvc/native_client/trunk/src/native_client/pnacl/d...
 SetUpLinkOptions
278  if env.getbool('NONSFI_NACL'):
279    # "_begin" allows a PIE to find its load address in order to apply
280    # dynamic relocations.
281    env.append('LD_FLAGS', '-defsym=_begin=0')
282    if env.getbool('USE_IRT'):
283      env.append('LD_FLAGS', '-pie')
284    else:

USE_IRT=1 unless --noirt is passed via -Wt,noirt, and it seems like nobody
is doing that, so -pie is passed on when nexe is generated, which results
in a library that requires INTERP=/usr/lib/libc.so.1
Adding -static instead of -pie would make it run and immediately segfault.

/ssd/nacl1/native_client/toolchain/linux_x86/pn\
acl_newlib/bin/pnacl-clang++ -arch x86-32-nonsfi
-B/ssd/nacl1/native_client/scons-out/nacl-x86-32-pnacl-nonsfi-clang/lib/
-Wl,-\
rpath-link,scons-out/nacl-x86-32-pnacl-nonsfi-clang/lib
-Wl,-rpath-link,toolchain/linux_x86/pnacl_newlib/lib -Wl,-rpath-link,sc\
ons-out/nacl-x86-32-pnacl-nonsfi-clang/lib -O3 -static
--pnacl-disable-abi-check scons-out/nacl-x86-32-pnacl-nonsfi-clang/obj/t\
ests/hello_world/hello_world.bc
-Lscons-out/nacl-x86-32-pnacl-nonsfi-clang/lib
-Ltoolchain/linux_x86/pnacl_newlib/lib -Lscons-o\
ut/nacl-x86-32-pnacl-nonsfi-clang/lib -lnacl_sys_private -lpthread_private
-o scons-out/nacl-x86-32-pnacl-nonsfi-clang/obj/test\
s/hello_world/hello_world.nexe --pnacl-driver-verbose

gdb

scons-out/nacl-x86-32-pnacl-nonsfi-clang/obj/tests/hello_world/hello_world.nexe

(gdb) run

Starting program:
/ssd/nacl1/native_client/scons-out/nacl-x86-32-pnacl-nonsfi-clang/obj/tests/hello_world/hello_world.nexe



Program received signal SIGSEGV, Segmentation fault.

0x0804d223 in __pnacl_init_irt ()

(gdb) bt

#0  0x0804d223 in __pnacl_init_irt ()



Hmmm.... this looks wrong.



2014-09-24 14:37 GMT+09:00 Junichi Uekawa (上川純一) <uekawa@google.com>:

> Hmm... run_exception_test also fails, so I've tried to understand what's
> going on. I took a look at run_hello_world_test because that seems to be
> much simpler to tackle and fails with same error message as
> run_exception_test.
>
> ./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32
>
> Compiles and runs fine.
>
> ./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32 nonsfi_nacl=1
>
> Does not compile, because gcc doesn't like -target=
>
> ./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32 nonsfi_nacl=1 bitcode=1
>
> Compiles and runs fine.
>
> ./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32 nonsfi_nacl=1 bitcode=1 pnacl_generate_pexe=0
>
> Fails to run, with "exception: [Errno 2] No such file or directory"
>
> This message seems to be coming from INTERP=/usr/lib/libc.so.1 which doesn't
exist but don't really know where it comes from.
>
>
>
>
> 2014-09-24 11:59 GMT+09:00 Mark Seaborn <mseaborn@chromium.org>:
>
>> On 19 September 2014 00:20, <uekawa@chromium.org> wrote:
>>>
>>> There's bunch of TLS-related symbols on x86-32.
>>>
>>> $ objdump -R
>>> scons-out/nacl_irt_test-x86-32-pnacl-nonsfi-clang/obj/
>>> tests/exception_test/exception_test_x86-32.nexe
>>>   .
>>>   .
>>>   .
>>> 00011bd8 R_386_GLOB_DAT    __tls_template_tdata_end
>>> 00011bd4 R_386_GLOB_DAT    __tls_template_start
>>> 00011bdc R_386_GLOB_DAT    __tls_template_end
>>> 00011bd0 R_386_GLOB_DAT    __tls_template_alignment
>>> 00011bc4 R_386_GLOB_DAT    __nacl_main
>>> 00011bcc R_386_GLOB_DAT    __ehdr_start
>>> 00011c0c R_386_TLS_TPOFF   _impure_ptr
>>
>>
>> Hmm.  I investigated this a bit, and I see what is going on.
>>
>> Let's back up a bit.  Bear in mind that exception_test is built using a
>> mode that hasn't been tested so far.  It is built with
>> "--pnacl-allow-translate" + "--pnacl-allow-native" + "-arch x86-32-nonsfi"
>> -- which Hidehiko has already been using for building nacl_helper_nonsfi.
>> However, it hasn't been tested for building nexes that follow the
>> x86-32-nonsfi ABI, and so use IRT interfaces, etc.  (nacl_helper_nonsfi
>> itself, as an executable, doesn't have to follow the x86-32-nonsfi ABI --
>> it makes Linux syscalls directly.)
>>
>> So first it would be good to check a more minimal example than
>> exception_test, to check whether this mode of the toolchain can
>> successfully produce working IRT-using nexes.
>>
>> This more minimal test shows that this mode doesn't work yet:
>>
>> $ cat hellow.c
>> #include <stdio.h>
>> int main() {
>>   printf("Hello, world!\n");
>>   return 0;
>> }
>> $ pnacl-clang --pnacl-allow-translate hellow.c -arch x86-32-nonsfi -c
>> $ pnacl-clang --pnacl-allow-native hellow.o -arch x86-32-nonsfi -o
>> hellow.nexe
>> $
>>
~/devel/nacl-git3/native_client/scons-out/nacl-x86-32-pnacl-pexe-nonsfi-clang/staging/nonsfi_loader.nexe
>> hellow.nexe
>> Illegal instruction (core dumped)
>>
>> GDB shows that this hits the same unhandled_relocation() failure that you
>> hit with exception_test.
>>
>> You're running into two problems, for the two relocation types you're
>> seeing above (R_386_GLOB_DAT and R_386_TLS_TPOFF):
>>
>>  * The GLOB_DAT problem is caused by weak symbols, and would be fairly
>> easy to fix (or at least work around).
>>  * The TPS_TPOFF problem is harder to fix, for IRT-using executables.
>>
>> (I can go into more of the details later.)
>>
>> I would suggest that you try getting the non-IRT-using version of
>> exception_test to build first, since the non-IRT-using case is what works
>> more readily when using "--pnacl-allow-translate".  That is, try
>> "run_exception_test" rather than "run_exception_test_irt".
>>
>> Cheers,
>> Mark
>>
>>
>
>
> --
> Junichi Uekawa
> Google
>



-- 
Junichi Uekawa
Google

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[Mark Seaborn, 2014-09-24 21:53:07]

On 23 September 2014 23:21, Junichi Uekawa (上川純一) <uekawa@google.com> wrote:

>
>
https://src.chromium.org/viewvc/native_client/trunk/src/native_client/pnacl/d...
>  SetUpLinkOptions
> 278  if env.getbool('NONSFI_NACL'):
> 279    # "_begin" allows a PIE to find its load address in order to apply
> 280    # dynamic relocations.
> 281    env.append('LD_FLAGS', '-defsym=_begin=0')
> 282    if env.getbool('USE_IRT'):
> 283      env.append('LD_FLAGS', '-pie')
> 284    else:
>
> USE_IRT=1 unless --noirt is passed via -Wt,noirt, and it seems like nobody
> is doing that, so -pie is passed on when nexe is generated, which results
> in a library that requires INTERP=/usr/lib/libc.so.1
> Adding -static instead of -pie would make it run and immediately segfault.
>

Indeed.  I can reproduce the problem of getting INTERP=/usr/lib/libc.so.1
above.

However, with the following patch, run_hello_world_test works, and I don't
get a segfault:

--- a/SConstruct
+++ b/SConstruct
@@ -3331,7 +3331,7 @@ irt_variant_tests = [
     'tests/performance/nacl.scons',
     'tests/pnacl_abi/nacl.scons',
     'tests/pnacl_dynamic_loading/nacl.scons',
-    'tests/pnacl_native_objects/nacl.scons',
+    #'tests/pnacl_native_objects/nacl.scons',
     'tests/process_create/nacl.scons',
     'tests/random/nacl.scons',
     'tests/redir/nacl.scons',
@@ -3700,7 +3700,7 @@ if nacl_env.Bit('nonsfi_nacl'):
   # involves using inline assembly, this requires turning off the PNaCl ABI
   # checker.
   nacl_env.SetBits('nonstable_bitcode')
-  nacl_env.Append(LINKFLAGS=['--pnacl-disable-abi-check'])
+  nacl_env.Append(LINKFLAGS=['--pnacl-disable-abi-check',
'--pnacl-allow-native', '-Wt,--noirt'])
   # Tell the PNaCl translator to link a Linux executable.
   nacl_env.Append(TRANSLATEFLAGS=['--noirt'])

This test run worked:

./scons -j4 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
platform=x86-32 nonsfi_nacl=1 bitcode=1 naclsdk_validate=0
pnacl_generate_pexe=0

Cheers,
Mark

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[native-client-reviews_googlegroups.com, 2014-09-25 05:38:45]

To reduce the number of things that are broken in the tree, I've sent out
https://codereview.chromium.org/599353002/

Error message from tests/pnacl_native_objects/nacl.scons looks convoluted
enough I haven't figured out how to fix that.



$ ./scons -j20 --mode=dbg-host,nacl,nacl_irt_test run_mmap_test_irt
platform=x86-32 nonsfi_nacl=1 bitcode=1 pnacl_generate_pexe=0 --verbose

AttributeError: 'NoneType' object has no attribute 'name':
  File "/ssd/nacl2/native_client/SConstruct", line 4005:
    BuildEnvironments(selected_envs)
  File "./site_scons/site_init.py", line 190:
    e.ExecuteDefer()
  File
"/usr/local/google/home/uekawa/src/nacl2/third_party/scons-2.0.1/engine/SCons/Environment.py",
line 222:
    return self.method(*nargs, **kwargs)
  File "/ssd/nacl2/native_client/site_scons/site_tools/defer.py", line 172:
    func(env)
  File "./site_scons/site_init.py", line 118:
    exports={'env': ec}, duplicate=0)
  File
"/usr/local/google/home/uekawa/src/nacl2/third_party/scons-2.0.1/engine/SCons/Script/SConscript.py",
line 551:
    return _SConscript(self.fs, *files, **subst_kw)
  File
"/usr/local/google/home/uekawa/src/nacl2/third_party/scons-2.0.1/engine/SCons/Script/SConscript.py",
line 260:
    exec _file_ in call_stack[-1].globals
  File "/ssd/nacl2/native_client/tests/pnacl_native_objects/nacl.scons",
line 34:
    bc_env.ComponentLibrary('bcsym_a', [bc_a]))
  File
"/usr/local/google/home/uekawa/src/nacl2/third_party/scons-2.0.1/engine/SCons/Environment.py",
line 222:
    return self.method(*nargs, **kwargs)
  File "/ssd/nacl2/native_client/site_scons/site_tools/replicate.py", line
87:
    target_name = env.Dir(target_entry).abspath + '/' + s.name


2014-09-25 6:52 GMT+09:00 Mark Seaborn <mseaborn@chromium.org>:

> On 23 September 2014 23:21, Junichi Uekawa (上川純一) <uekawa@google.com>
> wrote:
>
>>
>>
https://src.chromium.org/viewvc/native_client/trunk/src/native_client/pnacl/d...
>>  SetUpLinkOptions
>> 278  if env.getbool('NONSFI_NACL'):
>> 279    # "_begin" allows a PIE to find its load address in order to apply
>> 280    # dynamic relocations.
>> 281    env.append('LD_FLAGS', '-defsym=_begin=0')
>> 282    if env.getbool('USE_IRT'):
>> 283      env.append('LD_FLAGS', '-pie')
>> 284    else:
>>
>> USE_IRT=1 unless --noirt is passed via -Wt,noirt, and it seems like
>> nobody is doing that, so -pie is passed on when nexe is generated, which
>> results in a library that requires INTERP=/usr/lib/libc.so.1
>> Adding -static instead of -pie would make it run and immediately segfault.
>>
>
> Indeed.  I can reproduce the problem of getting INTERP=/usr/lib/libc.so.1
> above.
>
> However, with the following patch, run_hello_world_test works, and I don't
> get a segfault:
>
> --- a/SConstruct
> +++ b/SConstruct
> @@ -3331,7 +3331,7 @@ irt_variant_tests = [
>      'tests/performance/nacl.scons',
>      'tests/pnacl_abi/nacl.scons',
>      'tests/pnacl_dynamic_loading/nacl.scons',
> -    'tests/pnacl_native_objects/nacl.scons',
> +    #'tests/pnacl_native_objects/nacl.scons',
>      'tests/process_create/nacl.scons',
>      'tests/random/nacl.scons',
>      'tests/redir/nacl.scons',
> @@ -3700,7 +3700,7 @@ if nacl_env.Bit('nonsfi_nacl'):
>    # involves using inline assembly, this requires turning off the PNaCl
> ABI
>    # checker.
>    nacl_env.SetBits('nonstable_bitcode')
> -  nacl_env.Append(LINKFLAGS=['--pnacl-disable-abi-check'])
> +  nacl_env.Append(LINKFLAGS=['--pnacl-disable-abi-check',
> '--pnacl-allow-native', '-Wt,--noirt'])
>    # Tell the PNaCl translator to link a Linux executable.
>    nacl_env.Append(TRANSLATEFLAGS=['--noirt'])
>
> This test run worked:
>
> ./scons -j4 --mode=dbg-host,nacl,nacl_irt_test run_hello_world_test
> platform=x86-32 nonsfi_nacl=1 bitcode=1 naclsdk_validate=0
> pnacl_generate_pexe=0
>
> Cheers,
> Mark
>
>


-- 
Junichi Uekawa
Google

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to native-client-reviews+unsubscribe@googlegroups.com.
To post to this group, send email to native-client-reviews@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-reviews.
For more options, visit https://groups.google.com/d/optout.

[Junichi Uekawa, 2014-09-29 07:32:30]

updated and now it passes for run_exception_test on x86-32.

https://codereview.chromium.org/544003002/diff/200001/tests/exception_test/ex...
File tests/exception_test/exception_test.c (right):

https://codereview.chromium.org/544003002/diff/200001/tests/exception_test/ex...
tests/exception_test/exception_test.c:443: nonsfi_initialize_signal_handler();
I couldn't find a reasonable place to do initialization, this is usually called
from nonsfi_loader during initialization, but for all other cases I'm not sure
when to do that. Discussed with hamaji and we could do it before _start() or
very early in initialization, but I'm not too comfortable doing it that early in
all binaries.

[Mark Seaborn, 2014-09-30 00:12:48]

I tried applying the patch locally.  I get:

$ ./scons run_exception_test nonsfi_nacl=1 bitcode=1 -j4 naclsdk_validate=0
pnacl_generate_pexe=0 platform=arm
...
tests/exception_test/exception_test.c:17:10: fatal error: 
      'native_client/src/nonsfi/linux/irt_exception_handling.h' file not found

Can you make this a standalone change that can be committed first, please, by
undoing the changes to exception_test.c for now?

Let's just get exception_test to link on ARM first (and not necessarily on
x86-32).

[Junichi Uekawa, 2014-09-30 00:35:16]

On 2014/09/30 00:12:48, Mark Seaborn wrote:
> I tried applying the patch locally.  I get:
> 
> $ ./scons run_exception_test nonsfi_nacl=1 bitcode=1 -j4 naclsdk_validate=0
> pnacl_generate_pexe=0 platform=arm
> ...
> tests/exception_test/exception_test.c:17:10: fatal error: 
>       'native_client/src/nonsfi/linux/irt_exception_handling.h' file not found
> 
> Can you make this a standalone change that can be committed first, please, by
> undoing the changes to exception_test.c for now?
> 
> Let's just get exception_test to link on ARM first (and not necessarily on
> x86-32).

I've made 
 ./scons -j20 --mode=dbg-host,nacl_irt_test bitcode=1 nonsfi_nacl=1 
pnacl_generate_pexe=0   use_newlib_nonsfi_loader=0 platform=arm --verbose
run_exception_test                                                              
                 
 ./scons -j20 --mode=dbg-host,nacl_irt_test bitcode=1 nonsfi_nacl=1 
pnacl_generate_pexe=0   use_newlib_nonsfi_loader=0 platform=x86-32 --verbose
run_exception_test                                                              
                 

to stop after "Running test_exceptions_minimally..." and catch segv and fail
(because there's no exception handler for nonsfi yet).

[Junichi Uekawa, 2014-09-30 00:35:30]

https://codereview.chromium.org/544003002/diff/220001/SConstruct
File SConstruct (right):

https://codereview.chromium.org/544003002/diff/220001/SConstruct#newcode698
SConstruct:698: 'run_exception_test',  # TODO(uekawa): disable before submitting
because it fails.
I think I should disable this configuration before submitting, then reenable
when IRT implementation lands.

[Mark Seaborn, 2014-09-30 01:12:01]

https://codereview.chromium.org/544003002/diff/220001/SConstruct
File SConstruct (right):

https://codereview.chromium.org/544003002/diff/220001/SConstruct#newcode698
SConstruct:698: 'run_exception_test',  # TODO(uekawa): disable before submitting
because it fails.
On 2014/09/30 00:35:30, Junichi Uekawa wrote:
> I think I should disable this configuration before submitting, then reenable
> when IRT implementation lands.

Yes, you'd need to remove this line as per your comment in the code.

https://codereview.chromium.org/544003002/diff/220001/tests/exception_test/ex...
File tests/exception_test/exception_test.c (right):

https://codereview.chromium.org/544003002/diff/220001/tests/exception_test/ex...
tests/exception_test/exception_test.c:185: if (NONSFI_MODE) {
Would you mind undoing these changes in this file for now?  As a first step,
let's first just get committed a version that compiles and links for ARM, before
making the test pass.

[Junichi Uekawa, 2014-09-30 01:19:07]

ptal

https://codereview.chromium.org/544003002/diff/220001/tests/exception_test/ex...
File tests/exception_test/exception_test.c (right):

https://codereview.chromium.org/544003002/diff/220001/tests/exception_test/ex...
tests/exception_test/exception_test.c:185: if (NONSFI_MODE) {
On 2014/09/30 01:12:01, Mark Seaborn wrote:
> Would you mind undoing these changes in this file for now?  As a first step,
> let's first just get committed a version that compiles and links for ARM,
before
> making the test pass.

I've removed the changes related to making the test pass, and left the changes
that I made to let the test compile.

[Junichi Uekawa, 2014-09-30 01:46:58]

On 2014/09/30 01:19:07, Junichi Uekawa wrote:
> ptal
> 
>
https://codereview.chromium.org/544003002/diff/220001/tests/exception_test/ex...
> File tests/exception_test/exception_test.c (right):
> 
>
https://codereview.chromium.org/544003002/diff/220001/tests/exception_test/ex...
> tests/exception_test/exception_test.c:185: if (NONSFI_MODE) {
> On 2014/09/30 01:12:01, Mark Seaborn wrote:
> > Would you mind undoing these changes in this file for now?  As a first step,
> > let's first just get committed a version that compiles and links for ARM,
> before
> > making the test pass.
> 
> I've removed the changes related to making the test pass, and left the changes
> that I made to let the test compile.

ptal

made it to minimal code that makes ARM compile.

[Mark Seaborn, 2014-09-30 04:59:13]

LGTM, thanks.  Can you add a TEST= line, please, to say what Scons invocation
now succeeds?

https://codereview.chromium.org/544003002/diff/300001/SConstruct
File SConstruct (right):

https://codereview.chromium.org/544003002/diff/300001/SConstruct#newcode3031
SConstruct:3031: return False
Nit: fix indentation (remove 1 space)

[Junichi Uekawa, 2014-09-30 06:55:56]

https://codereview.chromium.org/544003002/diff/300001/SConstruct
File SConstruct (right):

https://codereview.chromium.org/544003002/diff/300001/SConstruct#newcode3031
SConstruct:3031: return False
On 2014/09/30 04:59:13, Mark Seaborn wrote:
> Nit: fix indentation (remove 1 space)

Done.

[Junichi Uekawa, 2014-09-30 07:03:36]

The CQ bit was checked by uekawa@chromium.org

[commit-bot: I haz the power, 2014-09-30 07:04:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/544003002/320001

[commit-bot: I haz the power, 2014-09-30 08:22:59]

Committed patchset #17 (id:320001) as 13806