Le 06/07/2021 à 15:50, Radu Rendec a écrit :
On Tue, 2021-07-06 at 15:16 +0200, Christophe Leroy wrote:
Le 06/07/2021 à 13:56, Radu Rendec a écrit :
On Tue, 2021-07-06 at 12:43 +0200, Christophe Leroy wrote:
Le 04/07/2021 à 23:38, Radu Rendec a écrit :
I'm trying to set up my (virtual) environment to test an old bug in the
PPC32 ptrace() code. I came across a completely different problem,
which seems to make gdb pretty much unusable on PPC32. I'm not sure if
this is a real kernel bug or maybe something wrong with my
configuration.
I'm running kernel 5.13 in a qemu VM with one e500mc CPU. I am running
native gdb (inside the VM) and setting a breakpoint in main() in a test
"hello world" program. Upon running the test program, I am hitting the
BUG_ON in do_notify_resume() on line 292. The kernel bug log snippet is
included below at the end of the email.
FWIW, gdb says:
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
I also added a pr_info() to do_notify_resume() just to see how much
different 'regs' and 'current->thread.regs' are. Surprisingly, they are
just 0x30 apart: regs=c7955f10 cur=c7955f40. Also, 'current' seems to
be OK (pid and comm are consistent with the test program).
The TRAP = 0x7d8 is obviously wrong.
Need to know which 'TRAP' it is exactly.
Could you try to dump what we have at the correct regs ?
Something like 'show_regs(current->thread.regs)' should do it.
Sure, please see the output below. It looks to me like the "correct"
regs are just garbage. Either they are overwritten or current->thread.regs
is wrong. But in any case, r1 = 0 doesn't look good.
Yes indeed. I think I identified the problem. For Critical interrupts like
DEBUG interrupt, struct
exception_regs is added, therefore the frame has 12x4 (0x30) more bytes. That's
what you see.
Commit
https://github.com/linuxppc/linux/commit/db297c3b07af7856fb7c666fbc9792d8e37556be#diff-dd6b952a3980da19df4facccdb4f3dddeb8cef56ee384c7f03d02b23b0c6cb26
Need to find the best solution now to fix that.
Awesome, happy to see you figured it out so quickly.
I'm not sure if it makes any sense, but one thing that comes to mind is
to put struct exception_regs before struct pt_regs when the frame is
saved. Unless of course other parts of the code expect the opposite.
Yes I think it is a good idea. I think I won't have time to look at that before
summer vacation though.
