[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ada035690e446909c3cdbf9a43a92def96020615.camel@xry111.site>
Date: Wed, 05 Jun 2024 23:13:43 +0800
From: Xi Ruoyao <xry111@...111.site>
To: Nathan Chancellor <nathan@...nel.org>, Peter Zijlstra
<peterz@...radead.org>
Cc: Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
Tiezhu Yang <yangtiezhu@...ngson.cn>, Nick Desaulniers
<ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>, Justin Stitt
<justinstitt@...gle.com>, Youling Tang <tangyouling@...inos.cn>, Jinyang He
<hejinyang@...ngson.cn>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
mengqinggang@...ngson.cn, cailulu@...ngson.cn, wanglei@...ngson.cn,
luweining@...ngson.cn, Yujie Liu <yujie.liu@...el.com>, Heng Qi
<hengqi@...ux.alibaba.com>, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] loongarch: Only select HAVE_OBJTOOL and allow ORC
unwinder if the inline assembler supports R_LARCH_{32,64}_PCREL
On Wed, 2024-06-05 at 21:18 +0800, Xi Ruoyao wrote:
> 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.
Another example: some simple rust code:
extern { fn f(x: &i64) -> i64; }
#[no_mangle]
fn g() -> i64 {
let x = 114514;
unsafe {f(&x)}
}
It's just lucky GCC doesn't use $fp as the frame pointer unless there's
some stupid code (VLA etc) thus the issue was not detected.
--
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University
Powered by blists - more mailing lists