llvm dev - Jun 2013 - [LLVMdev] Building a stable bitcode format for PNaCl - based on LLVM IR

> From the provided documentation I understood that in memory data
> structures of a PNaCl program are incompatible to the host program because
> ABIs are different (e.g. PNaCl pointers are always 32-bit even when running
> on x86_64 platform).
> So PNaCl program can't access any data structures of the host program
> directly. The only communication way is by using syscalls, but the document
> does not specify syscalls in detail.
>
We should probably clarify in the final documentation, but the goal of
PNaCl is to not only be portable and fast but also be safe for the user,
and the way this is achieved is through NaCl's SFI. Specifically for
syscalls:
  http://www.chromium.org/nativeclient/reference/anatomy-of-a-sys

In a way the syscalls offered are defined by the embedding sandbox: NaCl
through Chrome and sel_ldr have documented interfaces, and the NaCl SDK
offers POSIX-like interfaces built on top of these.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/5d983678/attachment.html>

Am 19.06.2013 18:01, schrieb JF Bastien:
>
>      From the provided documentation I understood that in memory data
>     structures of a PNaCl program are incompatible to the host program
>     because ABIs are different (e.g. PNaCl pointers are always 32-bit
>     even when running on x86_64 platform).
>     So PNaCl program can't access any data structures of the host
>     program directly. The only communication way is by using syscalls,
>     but the document does not specify syscalls in detail.
>
>
> We should probably clarify in the final documentation, but the goal of
> PNaCl is to not only be portable and fast but also be safe for the user,
> and the way this is achieved is through NaCl's SFI. Specifically for
> syscalls:
> http://www.chromium.org/nativeclient/reference/anatomy-of-a-sys
> In a way the syscalls offered are defined by the embedding sandbox: NaCl
> through Chrome and sel_ldr have documented interfaces, and the NaCl SDK
> offers POSIX-like interfaces built on top of these.
But this discussion is about stable bitcode format, or do you want to 
restrict the set of syscalls on the LLVM level ?
I am interested for my project in having a stable portable bitcode 
format like the one you propose, but not as a part of a browser and I 
possibly need to have an extended set of syscalls. The documentation 
does not provide an example how the syscall is represented in the LLVM 
bitcode. Is this just a function call ?

Best,

Dmitri

On Wed, Jun 19, 2013 at 12:42 PM, Dmitri Rubinstein <
dmitri.rubinstein at googlemail.com> wrote:
> Am 19.06.2013 18:01, schrieb JF Bastien:
>
>
>>      From the provided documentation I understood that in memory data
>>     structures of a PNaCl program are incompatible to the host program
>>     because ABIs are different (e.g. PNaCl pointers are always 32-bit
>>     even when running on x86_64 platform).
>>     So PNaCl program can't access any data structures of the host
>>     program directly. The only communication way is by using syscalls,
>>     but the document does not specify syscalls in detail.
>>
>>
>> We should probably clarify in the final documentation, but the goal of
>> PNaCl is to not only be portable and fast but also be safe for the
user,
>> and the way this is achieved is through NaCl's SFI. Specifically
for
>> syscalls:
>>
http://www.chromium.org/**nativeclient/reference/**anatomy-of-a-sys<http://www.chromium.org/nativeclient/reference/anatomy-of-a-sys>
>> In a way the syscalls offered are defined by the embedding sandbox:
NaCl
>> through Chrome and sel_ldr have documented interfaces, and the NaCl SDK
>> offers POSIX-like interfaces built on top of these.
>>
>
> But this discussion is about stable bitcode format, or do you want to
> restrict the set of syscalls on the LLVM level ?
> I am interested for my project in having a stable portable bitcode format
> like the one you propose, but not as a part of a browser and I possibly
> need to have an extended set of syscalls. The documentation does not
> provide an example how the syscall is represented in the LLVM bitcode. Is
> this just a function call ?

Yes - it's just a function call. The system calls are the same for NaCl and
PNaCl - they are part of the NaCl ABI but not part of the portable bitcode
language.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/d1980c4c/attachment.html>

On 19 June 2013 12:42, Dmitri Rubinstein
<dmitri.rubinstein at googlemail.com>wrote:
> Am 19.06.2013 18:01, schrieb JF Bastien:
>
>>      From the provided documentation I understood that in memory data
>>     structures of a PNaCl program are incompatible to the host program
>>     because ABIs are different (e.g. PNaCl pointers are always 32-bit
>>     even when running on x86_64 platform).
>>     So PNaCl program can't access any data structures of the host
>>     program directly. The only communication way is by using syscalls,
>>     but the document does not specify syscalls in detail.
>>
>>
>> We should probably clarify in the final documentation, but the goal of
>> PNaCl is to not only be portable and fast but also be safe for the
user,
>> and the way this is achieved is through NaCl's SFI. Specifically
for
>> syscalls:
>>
http://www.chromium.org/**nativeclient/reference/**anatomy-of-a-sys<http://www.chromium.org/nativeclient/reference/anatomy-of-a-sys>
>> In a way the syscalls offered are defined by the embedding sandbox:
NaCl
>> through Chrome and sel_ldr have documented interfaces, and the NaCl SDK
>> offers POSIX-like interfaces built on top of these.
>>
>
> But this discussion is about stable bitcode format, or do you want to
> restrict the set of syscalls on the LLVM level ?
> I am interested for my project in having a stable portable bitcode format
> like the one you propose, but not as a part of a browser and I possibly
> need to have an extended set of syscalls. The documentation does not
> provide an example how the syscall is represented in the LLVM bitcode. Is
> this just a function call ?
>
Yes, any calls to interact with the world outside the sandbox are just done
via function calls.  The PNaCl program defines an entry point, _start(),
which gets passed a data structure containing a pointer to an interface
query function.  The user code can call this query function to get function
pointers for further interfaces such as write(), mmap(), thread_create(),
and others.  These interfaces are defined in
https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/untrusted/irt/irt.h?revision=11525.
This interface layer is already used by NaCl, so it's somewhat orthogonal
to PNaCl's subset of LLVM IR.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130619/820d9f3b/attachment.html>