[LLVMdev] Building a stable bitcode format for PNaCl - based on LLVM IR

[Eli Bendersky]

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>