Re: [PATCH v3 2/3] x86/signal: Rewire the restart_block() syscall to have a constant nr

[Andy Lutomirski <luto@amacapital.net>]

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.