On Jun 21, 2016 5:40 AM, "Pedro Alves" <pal...@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.
