Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 21 Jun 2016 09:32:23 -0700 | Subject | Re: [PATCH v3 2/3] x86/signal: Rewire the restart_block() syscall to have a constant nr |
| |
On Jun 21, 2016 5:40 AM, "Pedro Alves" <palves@redhat.com> wrote: > > Hi Andy, > > On 06/21/2016 12:39 AM, Andy Lutomirski wrote: > > Suppose a 64-bit task A traces a 32-bit task B. > > I gave your x86/ptrace branch a try: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/ptrace > > (this looks to be the same patch set.) > > Unfortunately, with gdb git master, I still get the > 64-bit ptracer x 32-bit ptracee problem: > > (gdb) r > Starting program: interrupt.32 > talk to me baby > ^C
I didn't try that particular experiment. But, from that email:
> After that, GDB can control the stopped inferior. To call function "func1()" of inferior, GDB need: Step 1, save current values of registers ($rax 0xfffffffffffffe00(64 bits -512) is cut to 0xfffffe00(32 bits -512) because inferior is a 32 bits program).
That sounds like it may be a gdb bug. Why does gdb truncate the register?
I haven't played with it recently, but, in my experience, gdb seems to work quite poorly in mixed-mode situations. For example, if you attach 64-bit gdb to qemu-system-x86_64's gdbserver, boot a 64-bit guest, and breakpoint in early 32-bit code, gdb tends to explode pretty badly.
On x86_64, I think gdb should treat CPU state as 64-bit no matter what. The fact that a 32-bit tracee code segment is in use shouldn't change much.
Admittedly the kernel doesn't really help. There is some questionable code involving which regsets to show to ptrace.
| |