Re: [PATCH] loongarch: Only select HAVE_OBJTOOL and allow ORC unwinder if the inline assembler supports R_LARCH_{32,64}_PCREL

[Huacai Chen]

On Mon, Jun 17, 2024 at 9:38 PM Xi Ruoyao <xry111@xxxxxxxxxxx> wrote:
>
> On Mon, 2024-06-17 at 21:11 +0800, Huacai Chen wrote:
>
>
>
> > > select HAVE_OBJTOOL if AS_HAS_EXPLICIT_RELOCS && AS_HAS_THIN_ADD_SUB && !CC_IS_CLANG && !RUST
> > Maybe we needn't consider RUST here?
>
> Rustc does use $fp that objtool cannot handle as at now.  It can be
> demonstrated with an over-aligned type, similar to Clang:
>
> $ cat t.rs
> #[repr(C, align(64))]
> struct X(i32);
>
> extern { fn f(x: &X) -> i64; }
>
> #[no_mangle]
> fn g() -> i64 {
>     let x = X(114514);
>     unsafe {f(&x)}
> }
> $ rustc t.rs --emit=asm --crate-type=staticlib -O
> $ grep fp t.s
>         st.d    $fp, $sp, 112
>         addi.d  $fp, $sp, 128
>         addi.d  $sp, $fp, -128
>         ld.d    $fp, $sp, 112
>
> The kernel uses rust-bindgen to generate some .rs file from C headers.
> And __attribute__((aligned(x))) is directly translated to
> repr(align(x)).  As __attribute__((aligned(x))) is very common in the
> kernel I expect objtool will fail to handle some object code from rustc.
My meaning is: the build robot doesn't enable RUST now (maybe I'm
wrong), and this problem will surely be fixed in future, so we can
make the condition as simple as possible.

Huacai

>
> > And can we think AS_HAS_THIN_ADD_SUB always imply
> > AS_HAS_EXPLICIT_RELOCS here?
>
> Maybe, AFAIK there's no assembler using thin add-sub but not explicit
> relocs.
>
> --
> Xi Ruoyao <xry111@xxxxxxxxxxx>
> School of Aerospace Science and Technology, Xidian University
>