Generate x86 binary code

[piranna]

I'm looking for a C/C++ compiler written in Javascript capable of generate Linux x86 .so files, something similar to LLVM.js + clangor and ccjs (unluckily all of them abandoned :-( ). My intention is to generate Node.js compiled modules from inside NodeOS. Do you think JsCpp is capable of doing this, or do you know of any other alternative?

[felixhao28]

I don't really understand your intention. NodeOS runs JS libraries hosted on NPM. How does that relate to compiling C/C++ into .so files?

Anyway, JSCPP is designed as an C++ interpreter which works completely different from a compiler. The only reusable code seems to be those pegjs files which defines C++ grammar. All other logic has to be written from new if you want to create a compiler.

So, your best option may just be taking over LLVM.js+clangor and making it work together again.

[piranna]

I don't really understand your intention. NodeOS runs JS libraries hosted on NPM. How does that relate to compiling C/C++ into .so files?

Because compiled modules like to ones used to access to the Linux syscalls or to some external libraries or use some v8/Node.js C/C++ APIs are .so files :-) When the module is downloaded from npm, it's downloaded it's C/C++ source code and compiled locally. All the ones based on node-gyp work this way, that's why it's needed a C/C++ compiler. ws, node-canvas... there's a lot of them

So, your best option may just be taking over LLVM.js+clangor and making it work together again.

Yes, somewhat it could be the ideal solution, but the project seems to be mostly abandoned... :-(

[felixhao28]

Interesting. So NodeOS can execute .so files as a part of a compiled module. In this case, how about compiling and packing LLVM and clang into .so files and then pack them into a compiled npm module?

[piranna]

So NodeOS can execute .so files as a part of a compiled module

No, it can't be able to execute them, but can use as libraries, and it's needed to be used some wrapper functions to convert data between Javascript objects and C/C++ primitives. In the future when there's native support for ffi there will be possible to use directly the .so files, but some conversions should be needed too.

how about compiling and packing LLVM and clang into .so

Interesting, some bindings for LLVM... Yeah, this could work, but then the cli tools would need to be rewritten in Javascript agains that bindings.

then pack them into a compiled npm module

It could be possible for some modules, but not for all of them. There are currently a long discussion about what to do with gyp, and this is taking in account that node-gyp is now in the core, imaging changing the compilers for some dependencies... No, this will not work.

[felixhao28]

If node-gyp is in the core of NodeJS, then supporting it should belong to the core of NodeOS IMO. I mean there should be a built-in command like gcc that designed exclusively for node-gyp installs, and cannot be triggered by user manually (to avoid confusion).

[felixhao28]

My point is, in this case, compiling C/C++ into native code should not be part of user-space behavior.

[piranna]

It's not in the core of Node.js "as is", but instead node-gyp became to be in the core of npm that itself became to be in the core of Node.js. Think about the fact that npm needs to call to an external git client, imagine try to embed a C compiler...

[piranna]

My point is, in this case, compiling C/C++ into native code should not be part of user-space behavior.

What do you mean by "user-space" here?

[felixhao28]

What do you mean by "user-space" here?

All installable programs are in user-space. Common OSs use binary code in user-space, but that's where NodeOS works differently by using JS code (npm package) in user-space. So, a C++-to-binary compiler should not be a npm package.

Given that node-gyp is meant to be a native build tool, and that "native" equals "JavaScript" on NodeOS, the most sensible thing is to make a C++-to-JS compiler which itself is presented as JS program. And that NodeOS should provide native Linux kernel APIs as NodeOS JavaScript APIs so that C++-to-JS compiler is possible. Well, both parts are hard, not to mention how slow it might be.

Considering the information I've gathered so far, I think wrapping LLVM and clang into a library with a JS cli may be the cheapest (in terms of development cost, compiling efficiency, target code efficiency) workaround, with the cost of having .so files sticking around in NodeOS system (and the security risks).

[piranna]

So, a C++-to-binary compiler should not be a npm package.

i somewhat agree, that's why I'm looking for a C/C++ compiler written (or transpiled) in Javascript that's a npm package and works on Node.js and can generate binary .so files :-)

Given that node-gyp is meant to be a native build tool, and that "native" equals "JavaScript" on NodeOS, the most sensible thing is to make a C++-to-JS compiler which itself is presented as JS program

You've got to the point :-D Yes, that's exactly what I'm looking for :-)

NodeOS should provide native Linux kernel APIs as NodeOS JavaScript APIs

This is not so important, since there's already a lot of binding libraries.

not to mention how slow it might be

That's not something that I'm too much worried about as far as the compiler does it's job :-)

Considering the information I've gathered so far, I think wrapping LLVM and clang into a library with a JS cli may be the cheapest (in terms of development cost, compiling efficiency, target code efficiency) workaround

Probably, but it could be a difficult and time-consuming task, but definitelly it would be the compiling-time faster solution.

with the cost of having .so files sticking around in NodeOS system

That's how Node.js works, there are .node files (Node.js compiled modules, it's said, .so files) everywhere as dependencies of the different libraries and applications. That's not an issue.

and the security risks

For example?

[felixhao28]

Probably, but it (wrapping LLVM and clang into a library with a JS cli) could be a difficult and time-consuming task, but definitelly it would be the compiling-time faster solution.

This should be much more achievable than the alternatives:

1. creating a new C/C++-to-JS compiler
2. making LLVM.js+clangor working
3. convincing NodeOS team to support C/C++ compiling (I don't know about this one)

For example?

Making a .so that terminates the V8 engine process in Linux kernel that runs all NodeOS programs. I don't know for sure if it is possible or not, but allowing user-space programs to talk to system component whose level is lower than OS itself sounds quite dangerous. (Imagine a software downloaded from internet can bypass device drivers and directly send instructions to the devices using physical ports)

[piranna]

convincing NodeOS team to support C/C++ compiling

What do you mean? Adding a binary C/C++ compiler to the system? No way. NodeOS is a minimalist system where users are isolated ones from others so anybody can build his own OS inside its own $HOME folder, adding a common global C/C++ compiler would be a step back in several ways and complicate things... An alternative would be to package a binary C/C++ compiler inside a npm package, that would be doable (the cross-compiler is a npm package itself), although strange.

Making a .so that terminates the V8 engine process in Linux kernel that runs all NodeOS programs. I don't know for sure if it is possible or not, but allowing user-space programs to talk to system component whose level is lower than OS itself sounds quite dangerous. (Imagine a software downloaded from internet can bypass device drivers and directly send instructions to the devices using physical ports)

Oh, no, there's not such an issue. Node.js is included inside the Linux kernel, that's true, but inside an initram so it's available on boot time.Besides that, it's executed just like on any other Linux system, and in fact when the boot process has finished there's no processes running as priviledge users besides logon to allow access to the users to their accounts or nodeos-reverse-proxy to allow to do it remotely. I invite you to take a look on the project and give us your impressions :-)