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

[rod7760]

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]

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

[antoyo]

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]

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]

Hi @antoyo,

Cool! Thanks.

[rod7760]

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]

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]

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

[antoyo]

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]

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

With rust-lang/gcc#52 and #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]

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.