On Mon, Jan 8, 2024 at 6:51 PM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > This is due to a difference in default options between the two compilers; the > kernel isn't linked against libc in either case. > > Your native compiler evidently has -moutline-atomics enabled in its default > options. With that enabled, the builtin atomics generate calls to out-of-line > functions which the kernel itself does not provide, and hence those result in a > link-time error. > > Your cross-compiler evidently does not have -moutline-atomics enabled in its > default options. Without that enabled, the builtin atomics generate inline > atomic instructions rather than function calls. Since these don't depend on > external functions there's no link-time error. > > If you pass 'mno-outline-atomics' to your native compiler, the problem should > disappear. > Right, this should be the root cause, just pass 'mno-outline-atomics' to my native compiler, the kernel link time issue doesn't show. But, I test a userland application with '__sync_val_compare_and_swap' used, for the 'aarch64-linux-gnu-gcc test.c', the 'nm a.out' will output: ... 0000000000000960 t __aarch64_cas4_sync 0000000000011011 B __aarch64_have_lse_atomics ... >From the above output, seems the cross compiler has '-moutline-atomics' enabled by default, also with 'aarch64-linux-gnu-gcc -mno-outline-atomics test.c', the 'nm a.out' doesn't show the '_aarch64_cas4_sync'. The same result for the native build for the same test.c, this result can't explain why the cross-compile linux kernel will not generate the link time error,... > > Mark.
