The C language runtime fails on the compilation step when there are global variable declarations without initializers

[ravi-ct]

Trying with clang as the runtime choice, any global variable declarations in the supplied C program results in the following error:

Preparing environment...

Runno crashed: Error: Prepare step returned a non-zero exit code

int a;
int main() {}

The same works with clangpp runtime.

I tried to emulate the same error by cloning https://github.com/binji/wasm-clang & making changes to the clang options there. I used the exact same ones as what runno is passing (basically, had to remove -x c++ from the args to clang to mimic runno's options). It works with the exact same root fs & wasm as runno's & it works fine there without any issues.

The main difference seems to be with the memory/fs implementation between runno & binji/wasm-clang.

[taybenlor]

Hey Ravi! Thanks for the very thorough bug report. Particularly for going out of your way to find a reproduction and to test it in another env.

I'll look into this when I have a chance, I'm currently travelling for work but should be back next week.

If you're interested in investigating further I'd be interested to see what is coming out over STDERR. If you look in the web console it should be logging it.

[ravi-ct]

Hey Ben,

Thanks for the quick response. We will continue to debug this at our end. We basically use your wasi runtime within our product which has use cases around executing user code within the browser. I will post here further findings.

For now, here's what's on the console of runno.dev (the non-zero exit code referred below is 134 - click here for the line of code on the main branch):

Error: Prepare step returned a non-zero exit code
    at u0 (index-437ecdfa.js:336:3682)
    at async u2.interactiveRunFS (index-437ecdfa.js:337:27)
    at async ih.interactiveRunFS (index-437ecdfa.js:341:1522)
interactiveRunFS @ index-437ecdfa.js:337
await in interactiveRunFS (async)
interactiveRunFS @ index-437ecdfa.js:341
run @ index-437ecdfa.js:341
await in run (async)
handleEvent @ index-437ecdfa.js:195
run @ index-437ecdfa.js:215
handleEvent @ index-437ecdfa.js:195

There are a number of debug statements for WASI calls, which probably are more useful.

[taybenlor]

If you try out the WASI playground on https://runno.dev/wasi with the same binary, flags, files, etc you should be able to see the STDOUT/STDERR which will help understand what Clang is doing.

Alternatively that stuff will be in the debug logs, but you have to expand them in the browser console.

[taybenlor]

I've just had a look at yeah, there's nothing coming out. Interesting problem! Might be a bug in an internal implementation detail of the filesystem.

[taybenlor]

I've got a Draft PR up with a reproducing test that fails here (#283). I'll work on figuring out the cause next.

[ravi-ct]

@taybenlor, looks like the following claim I made is not exactly correct.

I tried to emulate the same error by cloning https://github.com/binji/wasm-clang & making changes to the clang options there. I used the exact same ones as what runno is passing (basically, had to remove -x c++ from the args to clang to mimic runno's options). It works with the exact same root fs & wasm as runno's & it works fine there without any issues.

The main difference seems to be with the memory/fs implementation between runno & binji/wasm-clang.

The clang wasm there is identical to the one in runno. The reason why it worked there but not on runno is that the file name there is marked as test.cc. This seems to force clang to compile like c++ rather than c, inspite of removing -x c++ option from its args. The moment we change the file name there to test.c or use -x c, clang.wasm fails even using the FS impl of binji/wasm-clang repo. So my earlier claim is a misdirection unfortunately.

Now I am fairly confident that the issue is with the clang.wasm. Looks like you seem to have inherited this clang.wasm from @binji's fork of llvm (directly or indirectly) & we may have to find & resolve a bug in the source repo there.

Please let me know if there are any further findings from your end.

[taybenlor]

Thanks for the extra context! Yeah I absolutely use the clang.wasm file from binji's fork. I'd be interested in what you find out.

It's possible for me to change the way Runno works to save the file as program.cc if that will fix your bug. But it sounds like that isn't the right solution?

[ravi-ct]

Yeah, making that change doesn't make sense. That's not the right solution because that'd mean the supposed C runtime would support C++ features such as classes, etc.

I am trying to see if I can build clang wasm, based on the limited information available from @binji on his repos & the talks he gave. Please post here in case you do have any other solution.

[taybenlor]

I'm very much not an expert in clang, or C, or your use case.

I guess what I'd want to know is what the expected behaviour from Clang is, and whether there is some other way to trigger it or work around it.

Some outstanding questions:

• What is the expected behaviour from clang?
• Have you tried running this clang wasm binary with wasmtime to see if you can get better errors?
• Do you know what code path in clang is being triggered?
• Is this a bug in the WASI port or was it a bug in the clang version that was ported?

No need to answer them just trying to get stuff out of my brain.

[ravi-ct]

• What is the expected behaviour from clang?

the code must compile fine without clang erroring out

• Have you tried running this clang wasm binary with wasmtime to see if you can get better errors?

yep, but not much luck. We identified the exact same backtrace whether used with wasmtime or in browser

• Do you know what code path in clang is being triggered?

Didn't try to figure out from the mangled names in the backtrace. I don't plan to spend time on this. Perhaps it is too ambitious, but I am trying to see if I can build the latest llvm tools (including clang) to wasm.

• Is this a bug in the WASI port or was it a bug in the clang version that was ported?

It appears to be a bug in the WASI port because the same works fine directly on the x86_64 version of clang 8.0.1 (that's the version of clang.wasm too) when tried on godbolt

[taybenlor]

Okay, it sounds like this is well out of my area of expertise. Best of luck! Keep me updated.