Re: [Qemu-devel] [PATCH] x86: Fix x86_64 'g' packet response to gdb from 32-bit mode.

[Doug Evans]

On Fri, Nov 4, 2016 at 12:01 PM, Pedro Alves <address@hidden> wrote:
> On 11/04/2016 04:34 PM, Peter Maydell wrote:
>> On 4 November 2016 at 16:29, Richard Henderson <address@hidden> wrote:
>>> On 11/03/2016 05:35 PM, Doug Evans wrote:
>>>>
>>>> The remote protocol can't handle flipping back and forth
>>>> between 32-bit and 64-bit regs. To compensate, pretend "as if"
>>>> on 64-bit cpu when in 32-bit mode.
>>>>
>>>> Signed-off-by: Doug Evans <address@hidden>
>>>> ---
>>>>  target-i386/gdbstub.c | 52
>>>> ++++++++++++++++++++++++++++++++++++++-------------
>>>>  1 file changed, 39 insertions(+), 13 deletions(-)
>>>
>>>
>>> Reviewed-by: Richard Henderson <address@hidden>
>>
>> Has anybody ever looked at fixing this on the gdb end?
>> (There are some similar cases for ARM CPUs, and actually
>> being able to debug across 32/64 boundaries, big/little
>> endian boundaries etc would be quite handy in some
>> situations.)
>>
>
> A while ago I was chatting with Andy Lutomirski about this,
> and he was saying that at least for x86_64, he'd prefer if gdb
> always thought of the register file as 64-bit, even if
> in 16-bit/32-bit mode.
>
>  
> http://lists-archives.com/linux-kernel/28605147-x86-signal-rewire-the-restart_block-syscall-to-have-a-constant-nr.html
>  
> http://lists-archives.com/linux-kernel/28605329-x86-signal-rewire-the-restart_block-syscall-to-have-a-constant-nr.html
>
> I never followed up with that, which is totally lame of me.
>
> Even if we did that, when debugging 32-bit mode code,
> I think you'd want gdb to present a 32-bit view of the program,
> so that printing expressions uses the correct types,
> calling 32-bit/64-bit functions in the inferior builds
> a call frame using the right ABI, etc. (and that exposes
> other challenges like maybe needing to switch modes
> while the infcall is running if you call a function of
> the "wrong" mode, etc.)  I believe the MIPS 64-bit gdb port actually
> works that way - it always transfers 64-bit registers across the
> wire, and then gdb presents 32-bit registers to debugging an elf
> of a 32-bit ABI.  I think it's the only port that does that.
> Whatever approach is taken, I suspect that there's a good amount
> of work needed to make things work completely seamlessly, though.

I agree that in 32-bit mode gdb should present a 32-bit view of the
world to the user.
This needs to work in the absence of debug info, thus there needs to
be some protocol extension to provide this information (attaching it
to the stop notification is one way, though that'd be insufficient I
think).

In the general case (i.e., to handle all arches) it'd be insufficient
to rely on being able to just use the 64-bit wire format, but until
gdb can support arch-switching as needed here, it allows things to
work that previously caused things like "'g' packet too long" and
totally broke the user's debugging session.

I also agree this is a fair bit of work.