nacl_interp
can only be ran on Linux. This mean the target ᴏꜱ in the ᴇʟꜰ header is set to 0x7B (whereas normal nexe are ᴏꜱ independent).This means the loader isn’t sel_ldr but/lib64/ld-nacl-x86-64.so.1
. It also implies the INTERP
is set to /lib64/ld-nacl-x86-64.so.1.
I guess this change something
If yes, at which address ?
Yes, but without ELF headers. ELF headers usually reside in the beginning of code block and thus couldn't be loaded in code segment (when interpreted as code it wouldn't pass rules for code). Instead first page is copied, non mmap'ed - and ELF headers are replaced with HLT instructions.
What do you mean by "rebuild it without the original headers"? If it wouldn't be ELF file then loader wouldn't recognize it, obviously...
--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.
To post to this group, send email to native-client-discuss@googlegroups.com.
Visit this group at https://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.
I don't think so. Information about executable layout is only used by loader, I don't think it's passed around to user's program. You rarely need it, though: NaCl has very strict restrictions of what's allowed and what's not allowed and newlib-based toolchain defines appropriate symbols which you could use to find out where code segment resides and where data segment resides...
Yes, probably. But if you are creating this file then you have access to original, and if you are not then these addressed are not guaranteed to be provided...If you are using glibc and dynamically linked executables then it's a moot point, anyway: the binary which is loaded first would always be runnable-ld.so, you need to look a how IT loads the binary to see where it's placed and what's awailable.
objdump
objcopy could be used, I think, but I'm not a guru.