Re: [PATCH] loongarch: Only select HAVE_OBJTOOL and allow ORC unwinder if the inline assembler supports R_LARCH_{32,64}_PCREL
From: Xi Ruoyao
Date: Wed Jun 05 2024 - 09:41:39 EST
On Wed, 2024-06-05 at 18:57 +0800, Xi Ruoyao wrote:
> On Tue, 2024-06-04 at 23:25 -0700, Nathan Chancellor wrote:
> > On Wed, Jun 05, 2024 at 01:54:24PM +0800, Xi Ruoyao wrote:
> > > On Tue, 2024-06-04 at 22:43 -0700, Nathan Chancellor wrote:
> > > > For what it's worth, I have noticed some warnings with clang that I
> > > > don't see with GCC but I only filed an issue on our GitHub and never
> > > > followed up on the mailing list, so sorry about that.
> > > >
> > > > https://github.com/ClangBuiltLinux/linux/issues/2024
> > > >
> > > > Might be tangential to this patch though but I felt it was worth
> > > > mentioning.
> > >
> > > The warnings in GCC build is definitely the issue handled by this patch.
> > > But the warnings in Clang build should be a different issue. Can you
> > > attach the kernel/events/core.o file from the Clang build for analysis?
> > > I guess we need to disable more optimization...
> >
> > Sure thing. Let me know if there are any issues with the attachment.
>
> Thanks! I've simplified it and now even...
>
> .global test
> .type test,@function
> test:
>
> addi.d $sp,$sp,-448
> st.d $ra,$sp,440
> st.d $fp,$sp,432
> addi.d $fp,$sp,448
>
> # do something
>
> addi.d $sp,$fp,-448
> ld.d $fp,$sp,432
> ld.d $ra,$sp,440
> addi.d $sp,$sp,448
> ret
>
> .size test,.-test
>
> is enough to trigger a objtool warning:
>
> /home/xry111/t1.o: warning: objtool: test+0x20: return with modified stack frame
>
> And to me this warning is bogus?
Minimal C reproducer:
struct x { _Alignas(64) char buf[128]; };
void f(struct x *p);
void g()
{
struct x x = { .buf = "1145141919810" };
f(&x);
}
Then objtool is unhappy to the object file produced with "clang -c -O2"
from this translation unit:
/home/xry111/t2.o: warning: objtool: g+0x50: return with modified stack frame
It seems CFI_BP has a very specific semantic in objtool and Clang does
not operates $fp in the expected way. I'm not sure about my conclusion
though. Maybe Peter can explain it better.
--
Xi Ruoyao <xry111@xxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University