[Qemu-devel] Re: [PATCH v5 18/18] gdbstub: x86: Switch 64/32 bit registers dynamically

[Jan Kiszka <jan.kiszka@siemens.com>]

Paul Brook wrote:
>>> In the absence of real information gdb falls back to the current CPU
>>> mode, which is a bit in the CPU status register. Exactly which
>>> register/bit depends whether you're talking to an M-profile device.
>>> M-profile cores are identified based on the XML register descriptions. If
>>> you don't have an XML capable target then you don't get to debug
>>> M-profile devices.
>> ...and this surely doesn't map on x86 (yet): gdb has no clue at all
>> about the CPU mode as it has no clue about segments or control registers.
>>
>>> IIRC There's also a gdb option to override the fallback mode.
>> For x86, the core of the issue is a decoupled control of the gdb remote
>> protocol and the disassembly mode. I guess I have to dig a bit in the
>> code to see if the hard coupling we see in practice can be broken up.
>> Not according to the command help I found so far.
> 
> This is sounding a lot like "we can't be bothered fixing gdb, so we're going 
> to add ugly hacks to qemu instead". I don't find this a particularly 
> convincing argument.

I'll be the last to refuse getting rid of this switching once there is a
released gdb version which is smarter. But right now there is not even a
smart CVS revision.

Although gdb does have separate current_gdbarch (used by the
disassembler) and target_gdbarch (used by the remote connector),
gdbarch_update_p always changes both of them when invoking 'set arch'.
There are comments indicating that they are working on making gdb more
flexible here for at least 5 years now. Frankly, this doesn't suggest
that we'll see an improvement tomorrow nor that it would be easy for us
to provide some ad-hoc gdb patches to accelerate this. Nevertheless,
this topic will surely come up for us again when we'll try to integrate
our segmentation enhancements for gdb.

But for now we face a regression of qemu-system-x86_64 that only allows
to use it in long mode. And that is what my patch fixes again. I really
don't see why we should keep it broken until gdb is fixed just because
the concept is a bit "ugly".

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2 ES-OS
Corporate Competence Center Embedded Linux