Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autotools project fails to compile with -save-temps #133

Closed
orestisfl opened this issue May 14, 2020 · 5 comments
Closed

Autotools project fails to compile with -save-temps #133

orestisfl opened this issue May 14, 2020 · 5 comments

Comments

@orestisfl
Copy link
Contributor

Hello, I am trying to compile libsodium which has a shell script to build with WebAssembly support, using wasi-sdk.

The script executes correctly by default but when I try to add -save-temps to the CFLAGS, compilation stops after a bit with the following error:

  CC       crypto_onetimeauth/poly1305/libsodium_la-onetimeauth_poly1305.lo
  CC       crypto_onetimeauth/poly1305/donna/libsodium_la-poly1305_donna.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2-core.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2-encoding.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2-fill-block-ref.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2.lo
  CC       crypto_pwhash/argon2/libsodium_la-blake2b-long.lo
onetimeauth_poly1305.s:15:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32, i64, i32) -> (i32)
                                ^
onetimeauth_poly1305.s:33:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32, i64, i32) -> (i32)
                                ^
onetimeauth_poly1305.s:49:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32) -> (i32)
                                ^
onetimeauth_poly1305.s:66:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32, i64) -> (i32)
                                ^
onetimeauth_poly1305.s:82:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32) -> (i32)

I have confirmed that if I remove wasi-sdk and compile without a wasm target & modified sysroot, compilation works with -save-temps and I can see the temporary files as a result.

To illustrate, I have created 2 docker files for easy reproduction: https://gist.github.com/orestisfl/5b5b333d5da7001dc799abea719ad9cf
One patches out wasi-sdk from the script and adds -save-temps and one that just adds the -save-temps flag to $CFLAGS.

$ curl https://gist.githubusercontent.com/orestisfl/5b5b333d5da7001dc799abea719ad9cf/raw/bec7b18fb231bd768b42bcef82851e103b7333b5/remove-wasi.Dockerfile | docker build -t tmp - && docker run tmp
… succeeds
$ curl https://gist.githubusercontent.com/orestisfl/5b5b333d5da7001dc799abea719ad9cf/raw/363817ee21247e68890030f4fecf1dd2480e9957/wasm32-wasi.Dockerfile | docker build -t tmp - && docker run tmp
…
  CC       crypto_onetimeauth/libsodium_la-crypto_onetimeauth.lo
  CC       crypto_onetimeauth/poly1305/libsodium_la-onetimeauth_poly1305.lo
  CC       crypto_onetimeauth/poly1305/donna/libsodium_la-poly1305_donna.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2-core.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2-encoding.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2-fill-block-ref.lo
  CC       crypto_pwhash/argon2/libsodium_la-argon2.lo
  CC       crypto_pwhash/argon2/libsodium_la-blake2b-long.lo
onetimeauth_poly1305.s:15:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32, i64, i32) -> (i32)
                                ^
onetimeauth_poly1305.s:33:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32, i64, i32) -> (i32)
                                ^
onetimeauth_poly1305.s:49:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32) -> (i32)
                                ^
onetimeauth_poly1305.s:66:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32, i64) -> (i32)
                                ^
onetimeauth_poly1305.s:82:20: error: Unexpected token in operand: (
        i32.call_indirect       (i32, i32) -> (i32)
                                ^
Makefile:2512: recipe for target 'crypto_onetimeauth/poly1305/libsodium_la-onetimeauth_poly1305.lo' failed
make[3]: *** [crypto_onetimeauth/poly1305/libsodium_la-onetimeauth_poly1305.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/libsodium/src/libsodium'
make[2]: *** [check-recursive] Error 1
Makefile:3106: recipe for target 'check-recursive' failed
make[2]: Leaving directory '/libsodium/src/libsodium'
Makefile:400: recipe for target 'check-recursive' failed
make[1]: Leaving directory '/libsodium/src'
make[1]: *** [check-recursive] Error 1
Makefile:515: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1

Any workaround suggestions are extremely welcome.

Thank you

@sunfishcode
Copy link
Member

I can reproduce this error with this testcase:

int foo(int (*p)(void)) {
    return p();
}

compiling with -save-temps with the latest wasi-sdk release. It appears fixed on LLVM master, so it should be fixed next time we update wasi-sdk to a newer LLVM.

Compilation without -save-temps works, so one workaround would be to run the compiler twice, once with -save-temps to generate the temporary .s files, which are preserved even after the errors, and then again without -save-temps to generate a .o file.

@sbc100
Copy link
Member

sbc100 commented May 14, 2020

Interesting, I hadn't realized the -save-temps caused the MC layer not only output the assembler but also try to re-parse it. That makes full .s file round-tripping more critical than I had previously thought.

@orestisfl
Copy link
Contributor Author

Thank you both for your replies. I've pulled the newest LLVM here but now I get a different error:

clang -cc1as: fatal error: error in backend: symbol not found in type index space: .Ltypeindex0

Again, without -save-temps it works.

Let me know if I can provide further information.

@sbc100
Copy link
Member

sbc100 commented May 22, 2020

This is bug in the llvm itself and the .s assembly file handling. Can you open bug at bugs.llvm.org, and if possible attach the failing input file if you could? (either input source of bitcode file).

kildom pushed a commit to kildom/clang-wasi-port that referenced this issue Jul 14, 2021
alexcrichton pushed a commit to alexcrichton/wasi-sdk that referenced this issue Apr 5, 2023
This brings in the following changes:

f645f49 Update signal macros after upgrade to snapshot1 (WebAssembly#144)
8b3266d github actions: pin checkout action to v1 (WebAssembly#145)
410c660 Use constructor functions for optional init routines. (WebAssembly#142)
fe13053 c header generation updated for reorganized witx ast (WebAssembly#139)
cd74e1d Correct the version of WebAssembly#136 on master (WebAssembly#141)
446cb3f Wasi snapshot preview1 (WebAssembly#140)
54102f0 Ignore rights in libpreopen. (WebAssembly#129)
8c9e1c6 Make the `__original_main` definition weak, fixing -flto. (WebAssembly#138)
cf81683 Optimize `fmin`, `fmax`, etc. (WebAssembly#120)
deb8eae Don't pre-check capabilities in `openat`. (WebAssembly#130)
ca9046d Use consistent style for wasi-libc C source files. (WebAssembly#131)
951cc3e Fix unintended recursion in __wasilibc_register_preopened_fd. (WebAssembly#133)
5216983 Avoid a `strdup` call in `__wasilibc_populate_libpreopen`. (WebAssembly#128)
70099d4 Don't link in libpreopen initialization code when it isn't needed. (WebAssembly#127)
ec4549d Temporarily disable the use of `__heap_base`. (WebAssembly#132)
a214f1c Use __heap_base by dlmalloc (WebAssembly#114)
a94d2d0 Avoid varargs conventions when calling open (WebAssembly#126)
7fcc4f2 Revamp and simplify the libpreopen code. (WebAssembly#110)
eb7230c Remove more unsupported headers. (WebAssembly#123)
@abrown
Copy link
Collaborator

abrown commented Aug 8, 2023

wasi-sdk has upgraded its LLVM tree since this issue; this is likely resolved. We can reopen if it is not.

@abrown abrown closed this as completed Aug 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants