I've not spent much time with the PNaCl tooling so only understand PNaCl and NaCl from a high(ish) level. I thus haven't got a good working knowledge of the toolchain so some of my questions may have obvious, many times repeated answers. Apologies in advance if this is the case and please redirect me with extreme predjudice (the links are very welcome of course).I'd like to know whether the PNaCl toolchain is now an entirely separate fork from the LLVM mainline or whether it is compatible with it (or perhaps already integrated). I'm aware that PNaCl uses a frozen version of LLVM IR which is undoubtedly different from today's mainline version. Furthermore, I'm also aware of the significant ABI differences between native code compiled by a "standard" (read LLVM mainline) native compiler and the PNaCl backend for emitting native code. What I'd like to understand is a couple of things:- Does the PNaCl IR encode the sandbox ABI differences or are these determined entirely by the native compiler (this is more for personal interest/understanding)?
- Is it possible/feasible to convert mainline LLVM IR to NaCl native code?- Is it possible/feasible to convert mainline LLVM IR to PNaCl IR?
Feasible in the last two questions means that with a "sensible" amount of effort I could compile an LLVM toolchain to do this.My guess to the 2nd and 3rd question is no, but wanted to confirm from experts.Hope that's not too vague!Thanks
--
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-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.
On Thu, Jun 18, 2015 at 12:51 PM, Andrew Parker <andrew.j...@gmail.com> wrote:I've not spent much time with the PNaCl tooling so only understand PNaCl and NaCl from a high(ish) level. I thus haven't got a good working knowledge of the toolchain so some of my questions may have obvious, many times repeated answers. Apologies in advance if this is the case and please redirect me with extreme predjudice (the links are very welcome of course).I'd like to know whether the PNaCl toolchain is now an entirely separate fork from the LLVM mainline or whether it is compatible with it (or perhaps already integrated).
I'm aware that PNaCl uses a frozen version of LLVM IR which is undoubtedly different from today's mainline version.
Furthermore, I'm also aware of the significant ABI differences between native code compiled by a "standard" (read LLVM mainline) native compiler and the PNaCl backend for emitting native code. What I'd like to understand is a couple of things:- Does the PNaCl IR encode the sandbox ABI differences or are these determined entirely by the native compiler (this is more for personal interest/understanding)?
- Is it possible/feasible to convert mainline LLVM IR to NaCl native code?
- Is it possible/feasible to convert mainline LLVM IR to PNaCl IR?
No for both. LLVM uses some knowledge of the target platform at pretty early stages of compilation process. This makes IR platform-dependent which means it no longer portable. I guess some limited forms could be converted (no "struct" function paramenters, etc).
On 18 June 2015 at 07:02, Victor Khimenko <kh...@chromium.org> wrote:On Thu, Jun 18, 2015 at 12:51 PM, Andrew Parker <andrew.j...@gmail.com> wrote:I've not spent much time with the PNaCl tooling so only understand PNaCl and NaCl from a high(ish) level. I thus haven't got a good working knowledge of the toolchain so some of my questions may have obvious, many times repeated answers. Apologies in advance if this is the case and please redirect me with extreme predjudice (the links are very welcome of course).I'd like to know whether the PNaCl toolchain is now an entirely separate fork from the LLVM mainline or whether it is compatible with it (or perhaps already integrated).It is a branch, not a fork. We merge upstream LLVM into the PNaCl branch fairly regularly.You can inspect the current merge state by looking at the Git history:Are you asking what parts of (P)NaCl's functionality are in upstream LLVM and which aren't?
I'm aware that PNaCl uses a frozen version of LLVM IR which is undoubtedly different from today's mainline version.It's important to distinguish between:* IR -- the language (which can be represented in memory or serialised to a text or binary file)* bitcode format -- one way of serialising IR to a filePNaCl's bitcode format is a frozen, simplified version of mainline LLVM's bitcode format. PNaCl's bitcode format represents a subset of LLVM IR.
Note that the PNaCl toolchain is capable of reading and writing both mainline LLVM bitcode and PNaCl bitcode, and it can convert between the two.Furthermore, I'm also aware of the significant ABI differences between native code compiled by a "standard" (read LLVM mainline) native compiler and the PNaCl backend for emitting native code. What I'd like to understand is a couple of things:- Does the PNaCl IR encode the sandbox ABI differences or are these determined entirely by the native compiler (this is more for personal interest/understanding)?By "sandbox ABI" do you mean "how jumps, returns and memory accesses are sandboxed"? Those details are handled by the backend, and the IR is agnostic about those details.
- Is it possible/feasible to convert mainline LLVM IR to NaCl native code?Yes. The PNaCl toolchain can read mainline LLVM IR.
--
You received this message because you are subscribed to a topic in the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/native-client-discuss/IYwj5eECFVw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to native-client-di...@googlegroups.com.
This seems to contradict Victor's response in which he states:No for both. LLVM uses some knowledge of the target platform at pretty early stages of compilation process. This makes IR platform-dependent which means it no longer portable. I guess some limited forms could be converted (no "struct" function paramenters, etc).Can you clarify? I suspect maybe the issue is that both of you are correct. Perhaps PNaCl is capable of understanding the full LLVM language but platform dependencies mean the code simply would be incompatible.
For example, using sizeof(void*) in C++ code when compiled with a generic clang would produce an int which is bitness dependent. There are similar problems with endianess and lord knows what else. Is this the crux of the matter?
If so, then how does PNaCl handle this sort of thing? Using the example, how would PNaCl handle sizeof(void*)?
Actually, having just read your final point below I think I'm probably correct in my understanding here. I would guess this makes it pretty difficult to reuse code generated by a different front end.
--
You received this message because you are subscribed to a topic in the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/native-client-discuss/IYwj5eECFVw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to native-client-di...@googlegroups.com.