error: failed to run `rustc` during ./build.sh on aarch64

rod7760 commented 1 year ago

Hello. I get the following error when running ./build.sh —release.

I don't have much experience with rust or gcc, so I apologize if this is a vague question.

stderr

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -Cpanic=abort -Csymbol-mangling-version=v0 -Cdebuginfo=2 -Clto=off -Zpanic-abort-tests -Zcodegen-backend=/home/rick/Projects/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so --sysroot /home/rick/Projects/rustc_codegen_gcc/build_sysroot/sysroot --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit status: 4)
  --- stderr
  0xffff8585b16f jit_langhook_pushdecl
        ../../gcc/gcc/jit/dummy-frontend.cc:908
  0xffff861225d7 aarch64_init_simd_builtin_types
        ../../gcc/gcc/config/aarch64/aarch64-builtins.cc:1149
  0xffff861240db aarch64_init_simd_builtins
        ../../gcc/gcc/config/aarch64/aarch64-builtins.cc:1590
  0xffff861240db aarch64_general_init_builtins()
        ../../gcc/gcc/config/aarch64/aarch64-builtins.cc:1986
  0xffff8606b2cb aarch64_init_builtins
        ../../gcc/gcc/config/aarch64/aarch64.cc:15192
  0xffff8587186f jit_langhook_init
        ../../gcc/gcc/jit/dummy-frontend.cc:616
  0xffff85868c2b lang_dependent_init
        ../../gcc/gcc/toplev.cc:1815
  0xffff85868c2b do_compile
        ../../gcc/gcc/toplev.cc:2110

rod7760 commented 1 year ago

I may be messing something else up in the build steps. When running the libgccjit tests, what should the expected output be?

antoyo commented 1 year ago

I might have messed up the master branch of my GCC fork. I'll check that tomorrow.

The output of the tests looks like:

        === jit Summary ===

# of expected passes        15181

(not sure what the real number is, but you should not see much failures — there are a few failures currently, around 4, I believe)

antoyo commented 1 year ago

This actually seems like a bug in libgccjit: it seems like jit_langhook_pushdecl is called on the arch you're using (aarch64) and it's currently unimplemented.

rod7760 commented 1 year ago

Hi @antoyo,

Cool! Thanks.

rod7760 commented 1 year ago

Additional debug log from libgccjit:

JIT: libgccjit (GCC) version 13.0.0 20221214 (experimental) (aarch64-unknown-linux-gnu)
JIT:    compiled by GNU C version 9.4.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version none
JIT: entering: gcc_jit_context_set_bool_option
JIT:  GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE: false
JIT: exiting: gcc_jit_context_set_bool_option
JIT: entering: gcc_jit_context_get_type
JIT: exiting: gcc_jit_context_get_type
JIT: entering: gcc_jit_context_get_type
JIT: exiting: gcc_jit_context_get_type
JIT: entering: gcc_jit_context_new_param
JIT: exiting: gcc_jit_context_new_param
JIT: entering: gcc_jit_context_new_function
JIT: exiting: gcc_jit_context_new_function
JIT: entering: gcc_jit_context_new_param
JIT: exiting: gcc_jit_context_new_param
JIT: entering: gcc_jit_context_get_type
JIT: exiting: gcc_jit_context_get_type
JIT: entering: gcc_jit_context_new_function
JIT: exiting: gcc_jit_context_new_function
JIT: entering: gcc_jit_context_new_string_literal
JIT: exiting: gcc_jit_context_new_string_literal
JIT: entering: gcc_jit_function_new_block
JIT: exiting: gcc_jit_function_new_block
JIT: entering: gcc_jit_context_new_call
JIT: exiting: gcc_jit_context_new_call
JIT: entering: gcc_jit_block_add_eval
JIT: exiting: gcc_jit_block_add_eval
JIT: entering: gcc_jit_block_end_with_void_return
JIT: exiting: gcc_jit_block_end_with_void_return
JIT: entering: gcc_jit_context_compile
JIT:  in-memory compile of ctxt: 0x3ff3f9c0
JIT:  entering: gcc::jit::result* gcc::jit::recording::context::compile()
JIT:   GCC_JIT_STR_OPTION_PROGNAME: NULL
JIT:   GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL: 0
JIT:   GCC_JIT_BOOL_OPTION_DEBUGINFO: false
JIT:   GCC_JIT_BOOL_OPTION_DUMP_INITIAL_TREE: false
JIT:   GCC_JIT_BOOL_OPTION_DUMP_INITIAL_GIMPLE: false
JIT:   GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE: false
JIT:   GCC_JIT_BOOL_OPTION_DUMP_SUMMARY: false
JIT:   GCC_JIT_BOOL_OPTION_DUMP_EVERYTHING: false
JIT:   GCC_JIT_BOOL_OPTION_SELFCHECK_GC: false
JIT:   GCC_JIT_BOOL_OPTION_KEEP_INTERMEDIATES: false
JIT:   gcc_jit_context_set_bool_allow_unreachable_blocks: false
JIT:   gcc_jit_context_set_bool_use_external_driver: false
JIT:   gcc_jit_context_set_bool_print_errors_to_stderr: true
JIT:   entering: void gcc::jit::recording::context::validate()
JIT:   exiting: void gcc::jit::recording::context::validate()
JIT:   entering: gcc::jit::playback::context::context(gcc::jit::recording::context*)
JIT:   exiting: gcc::jit::playback::context::context(gcc::jit::recording::context*)
JIT:   entering: gcc::jit::playback::compile_to_memory::compile_to_memory(gcc::jit::recording::context*)
JIT:   exiting: gcc::jit::playback::compile_to_memory::compile_to_memory(gcc::jit::recording::context*)
JIT:   entering: void gcc::jit::playback::context::compile()
JIT:    entering: gcc::jit::tempdir::tempdir(gcc::jit::logger*, int)
JIT:    exiting: gcc::jit::tempdir::tempdir(gcc::jit::logger*, int)
JIT:    entering: bool gcc::jit::tempdir::create()
JIT:     m_path_template: /tmp/libgccjit-XXXXXX
JIT:     m_path_tempdir: /tmp/libgccjit-jaxmLR
JIT:    exiting: bool gcc::jit::tempdir::create()
JIT:    entering: void gcc::jit::playback::context::lock()
JIT:    exiting: void gcc::jit::playback::context::lock()
JIT:    entering: void gcc::jit::playback::context::make_fake_args(vec<char*, va_heap, vl_ptr>*, const char*, vec<gcc::jit::recording::requested_dump>*)
JIT:     getting configure-time options from driver
JIT:    exiting: void gcc::jit::playback::context::make_fake_args(vec<char*, va_heap, vl_ptr>*, const char*, vec<gcc::jit::recording::requested_dump>*)
JIT:    entering: toplev::main
JIT:     argv[0]: libgccjit.so
JIT:     argv[1]: /tmp/libgccjit-jaxmLR/fake.c
JIT:     argv[2]: -fPIC
JIT:     argv[3]: -O0
JIT:     argv[4]: -quiet
JIT:     entering: bool jit_langhook_init()
JIT:      entering: void jit_begin_diagnostic(diagnostic_context*, diagnostic_info*)
JIT:      exiting: void jit_begin_diagnostic(diagnostic_context*, diagnostic_info*)
JIT:      entering: void jit_end_diagnostic(diagnostic_context*, diagnostic_info*, diagnostic_t)
JIT:       entering: void gcc::jit::recording::context::add_error_va(gcc::jit::recording::location*, const char*, va_list)
JIT:        error 0: in jit_langhook_pushdecl, at jit/dummy-frontend.cc:908
libgccjit.so: <built-in>:0:0: error: in jit_langhook_pushdecl, at jit/dummy-frontend.cc:908
JIT:       exiting: void gcc::jit::recording::context::add_error_va(gcc::jit::recording::location*, const char*, va_list)
JIT:      exiting: void jit_end_diagnostic(diagnostic_context*, diagnostic_info*, diagnostic_t)
0xffffbb53bbdf jit_langhook_pushdecl
        ../../gcc/gcc/jit/dummy-frontend.cc:908
0xffffbbe10eff aarch64_init_simd_builtin_types
        ../../gcc/gcc/config/aarch64/aarch64-builtins.cc:1149
0xffffbbe12a03 aarch64_init_simd_builtins
        ../../gcc/gcc/config/aarch64/aarch64-builtins.cc:1590
0xffffbbe12a03 aarch64_general_init_builtins()
        ../../gcc/gcc/config/aarch64/aarch64-builtins.cc:1986
0xffffbbd5a7d3 aarch64_init_builtins
        ../../gcc/gcc/config/aarch64/aarch64.cc:15204
0xffffbb5522df jit_langhook_init
        ../../gcc/gcc/jit/dummy-frontend.cc:616
0xffffbb54969b lang_dependent_init
        ../../gcc/gcc/toplev.cc:1815
0xffffbb54969b do_compile
        ../../gcc/gcc/toplev.cc:2110

rod7760 commented 1 year ago

Hi @antoyo.

I noticed in this PR you added support for i386 built-ins.

My arch calls add_builtin_type which calls lang_hooks.decls.pushdecl (decl);. Which explains the error.

However, I noticed that config/i386/i386-builtins.cc doesn't call lang_hooks.add_builtintype, but it does call lang_hooks.types.register_builtin_type. Example : here. I assume this means config/i386/i386-builtins.cc simply uses a different pattern/function to initialize builtins, and I could theoretically follow that pattern to initialize my builtins in config/aarch64/aarch64-builtins.cc to avoid a call to pushdecl.

I hope that makes sense. I have no idea how difficult that solution would be to execute, but I just wanted to check if I understood generally what was happening.

antoyo commented 1 year ago

I'm on vacation, so I cannot look at this. I'll check that in January.

antoyo commented 1 year ago

I haven't forgotten about this issue, but now is not a good time for me to check this. That'll probably take a few months before I'll take a look.

antoyo commented 2 months ago

Sorry it took so long for me to look at this.

With https://github.com/rust-lang/gcc/pull/52 and https://github.com/rust-lang/rustc_codegen_gcc/pull/504, I can now build the sysroot on Aarch64. Running a program built with the std immediately segfaults, though. I'll investigate this.

Edit: Some more info:

Compiling the sysroot in release mode fixes the segfault, seemingly because the following function push stuff on the stack, but doesn't pop it at the end (without optimizations):

Dump of assembler code for function __aarch64_cas8_relax:
0x0000aaaaaacdb9c8 <+0>: sub sp, sp, #0x20
0x0000aaaaaacdb9cc <+4>: str x0, [sp, #24]
0x0000aaaaaacdb9d0 <+8>: str x1, [sp, #16]
0x0000aaaaaacdb9d4 <+12>:    str x2, [sp, #8]
0x0000aaaaaacdb9d8 <+16>:    mov x16, x0
=> 0x0000aaaaaacdb9dc <+20>:    ldxr    x0, [x2]
0x0000aaaaaacdb9e0 <+24>:    cmp x0, x16
0x0000aaaaaacdb9e4 <+28>:    b.ne    0xaaaaaacdb9f0 <__aarch64_cas8_relax+40>  // b.any
0x0000aaaaaacdb9e8 <+32>:    stxr    w17, x1, [x2]
0x0000aaaaaacdb9ec <+36>:    cbnz    w17, 0xaaaaaacdb9dc <__aarch64_cas8_relax+20>
0x0000aaaaaacdb9f0 <+40>:    ret

Some std tests still don't pass (fixed by fixing an assert).
Now the rand tests don't pass, seemingly because we cannot fetch CPU features on other targets than x86 for now.

pinskia commented 2 months ago

RFC from rust: https://rust-lang.github.io/rfcs/2972-constrained-naked.html But note GCC does not implement naked attribute for all targets that includes (but not limited to) aarch64: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882 . Basically I think naked attribute should error out in this case.

antoyo commented 2 months ago

Also, many UI tests fail with undefined reference to '__atomic_store_16' and it looks like we should link libatomic on the rust side around here.

rust-lang / rustc_codegen_gcc

error: failed to run `rustc` during ./build.sh on aarch64 #242

stderr