Re: Issues compiling stand-alone NaCl applications with glibc toolchain

133 views
Skip to first unread message

Andrey Khalyavin

unread,
Oct 7, 2012, 11:49:00 AM10/7/12
to native-cli...@googlegroups.com
Try to replace ~ with actual directory in --library-path. runnable-ld.so may not know home directory.

Andrey Khalyavin

Victor Khimenko

unread,
Oct 7, 2012, 12:46:26 PM10/7/12
to native-cli...@googlegroups.com

On Sun, Oct 7, 2012 at 6:07 PM, Dilan Manatunga <mana...@gmail.com> wrote:
Hi, (Sorry if this is a double post, had issues with first post and not sure if it went through)

I have been working on compiling stand-alone NaCl applications with the newlib and gcc toolchain. Based on previous posts, I have been able to successfully compile and run a simple hello_world program using the new_lib toolchain and the following commands:
 ~/Research/nacl/nacl_sdk/pepper_22/toolchain/linux_x86_newlib/bin/x86_64-nacl-gcc -shared -fPIC hello_world.c -o hello_world_newlib.nexe
~/Research/nacl/nacl_sdk/pepper_22/tools/sel_ldr_x86_64 -Q -B ~/Research/nacl/nacl_sdk/pepper_22/tools/irt_x86_64.nexe hello_world_newlib.nexe 

PLATFORM QUALIFICATION DISABLED BY -Q - Native Client's sandbox will be unreliable!
[23502,4212565824:10:00:07.489401] Native Client module will be loaded at base address 0x00007f8a00000000
Hello World!

Based on this previous post (https://groups.google.com/forum/#!topic/native-client-discuss/WK0f53cTG0s/discussion) and the script referenced in the post (https://github.com/krasin/nacl_interp/blob/master/nacl_interp_loader_sdk.sh), I have been trying to compile and run the same hello_world program for the glibc toolchain. However, I keep getting errors based on the following commands:
 ~/Research/nacl/nacl_sdk/pepper_22/toolchain/linux_x86_glibc/bin/x86_64-nacl-gcc -shared -fPIC hello_world.c -o hello_world_glibc.nexe
~/Research/nacl/nacl_sdk/pepper_22/tools/sel_ldr_x86_64 -a -S -Q -B ~/Research/nacl/nacl_sdk/pepper_22/tools/irt_x86_64.nexe -- ~/Research/nacl/nacl_sdk/pepper_22/toolchain/linux_x86_glibc/x86_64-nacl/lib64/runnable-ld.so --library-path ~/Research/nacl/nacl_sdk/pepper_22/toolchain/linux_x86_glibc/x86_64-nacl/lib64 ./hello_world_glibc.nexe 
DEBUG MODE ENABLED (bypass acl)
PLATFORM QUALIFICATION DISABLED BY -Q - Native Client's sandbox will be unreliable!
[23498,3174541120:09:56:23.945739] BYPASSING ALL ACL CHECKS
[23498,3174541120:09:56:23.953188] Native Client module will be loaded at base address 0x00007fd600000000
[23498,3174463232:09:56:24.033812] NaClHostDescOpen: open returned -1, errno 2

I have managed to get around most of my errors by googling around, but I have no idea what to do with this problem.

Well, if something does not work in native case then why do you expect it'll work with NaCl?

$ gcc -shared -fPIC hello_world.c -o hello_world_glibc.nexe
$ /lib/ld-linux-x86-64.so.2 ./hello_world_glibc.nexe
Segmentation fault
$ gcc hello_world.c -o hello_world_glibc.nexe
$ /lib/ld-linux-x86-64.so.2 ./hello_world_glibc.nexe
Hello, World!

It's possible to create a library which can be started as an executable (GLibC itself is such a library, for example), but it's not a simple task and I'm not sure why you are trying to create such a beast instead of a simple .nexe.

Victor Khimenko

unread,
Oct 7, 2012, 10:51:43 PM10/7/12
to native-cli...@googlegroups.com

On Sun, Oct 7, 2012 at 11:28 PM, Dilan Manatunga <mana...@gmail.com> wrote:
Weirdly, when I used compiling a simple executable combined with the library technique, I still get the error, but Hello World! is also printed. Anyone can explain this?

I think it's classic "possibly you have misunderstood what the program is supposed to do, and you are both looking at exactly the same display but you think it's wrong and they know it's right" (from "How to Report Bugs Effectively": http://www.chiark.greenend.org.uk/~sgtatham/bugs.html ).

What error are you talking about? I don't see anything strange in your output...

~/Research/nacl/nacl_sdk/pepper_22/tools/sel_ldr_x86_64 -Q -B ~/Research/nacl/nacl_sdk/pepper_22/tools/irt_x86_64.nexe hello_world.nexe 
~/Research/nacl/nacl_sdk/pepper_22/tools/sel_ldr_x86_64 -a -S -Q -B ~/Research/nacl/nacl_sdk/pepper_22/tools/irt_x86_64.nexe -- ~/Research/nacl/nacl_sdk/pepper_22/toolchain/linux_x86_glibc/x86_64-nacl/lib64/runnable-ld.so --library-path ~/Research/nacl/nacl_sdk/pepper_22/toolchain/linux_x86_glibc/x86_64-nacl/lib64 ./hello_world.nexe DEBUG MODE ENABLED (bypass acl)
PLATFORM QUALIFICATION DISABLED BY -Q - Native Client's sandbox will be unreliable!
[21551,3107280704:15:27:05.342913] BYPASSING ALL ACL CHECKS
[21551,3107280704:15:27:05.346464] Native Client module will be loaded at base address 0x00007faa00000000
[21551,3107202816:15:27:05.424661] NaClHostDescOpen: open returned -1, errno 2

If you mean "NaClHostDescOpen: open returned -1, errno 2" then it's normal: GLibC tries to open few files which may or may not exist. Hard to say what exactly it tried to load here, but in my case it happens when it tries to find LinuxThread-compatible libgcc.so.1 :

$ strace -f scons-out/dbg-linux-x86-64/obj/src/trusted/service_runtime/sel_ldr -a -- toolchain/linux_x86/x86_64-nacl/lib64/runnable-ld.so --library-path $PWD/toolchain/linux_x86/x86_64-nacl/lib64 ./hello_world_glibc.nexe 2>&1 | grep -A 5 -B 1 'NaClHostDescOpen: open returned'
[pid 16732] open(".../toolchain/linux_x86/x86_64-nacl/lib64/tls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 16732] write(3, "[16729,2097780480:06:45:02.11080"..., 79[16729,2097780480:06:45:02.110805] NaClHostDescOpen: open returned -1, errno 2
) = 79
[pid 16732] stat(".../toolchain/linux_x86/x86_64-nacl/lib64/tls", 0x7fab7d098810) = -1 ENOENT (No such file or directory)
[pid 16732] stat(".../toolchain/linux_x86/x86_64-nacl/lib64/libgcc_s.so.1", {st_mode=S_IFREG|0644, st_size=525036, ...}) = 0
[pid 16732] open(".../linux_x86/x86_64-nacl/lib64/libgcc_s.so.1", O_RDONLY) = 13
[pid 16732] fstat(13, {st_mode=S_IFREG|0644, st_size=525036, ...}) = 0

As you can see GLibC tried to first find tls/libgcc_s.so.1 and when that failed it went and opened NPTL-compatible version of libgcc_s.so.1. Nothing strange here: native version does the same (the only difference is the fact that it does not report about these failures).

Hello World!

-Dilan

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/sM8ucJvR02gJ.

To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

Reply all
Reply to author
Forward
0 new messages