On 11/04/2016 04:34 PM, Peter Maydell wrote: > On 4 November 2016 at 16:29, Richard Henderson <r...@twiddle.net> 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 <d...@google.com> >>> --- >>> target-i386/gdbstub.c | 52 >>> ++++++++++++++++++++++++++++++++++++++------------- >>> 1 file changed, 39 insertions(+), 13 deletions(-) >> >> >> Reviewed-by: Richard Henderson <r...@twiddle.net> > > 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. Thanks, Pedro Alves