On Wed, 2024-06-05 at 21:18 +0800, Xi Ruoyao wrote:I think this because we did not add arch special handle in update_cfi_state().
On Wed, 2024-06-05 at 18:57 +0800, Xi Ruoyao wrote:Another example: some simple rust code:
On Tue, 2024-06-04 at 23:25 -0700, Nathan Chancellor wrote:Minimal C reproducer:
On Wed, Jun 05, 2024 at 01:54:24PM +0800, Xi Ruoyao wrote:Thanks! I've simplified it and now even...
On Tue, 2024-06-04 at 22:43 -0700, Nathan Chancellor wrote:Sure thing. Let me know if there are any issues with the attachment.
For what it's worth, I have noticed some warnings with clang that IThe warnings in GCC build is definitely the issue handled by this patch.
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.
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...
.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?
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.
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.