Re: [Qemu-devel] Re: gdbstub: packet reply is too long

[Jan Kiszka]

Paul Brook wrote:
>> Well, I'm using gdb over qemu and kvm in precisely that hybrid
>> scenarios, but also in normal ones. Heavily. And I'm only able to do
>> this because of the workaround. But I'm willing to learn about scenarios
>> where it causes /regressions/.
> 
> I find that hard to believe. Doesn't it break horribly as soon as the CPU 
> switches modes?

It still breaks in very few corner cases, but that's (most probably) due
to the fact the gdb is not yet well prepared to switch sub-architectures
properly during runtime. However, it only breaks in cases that wouldn't
work without the switching anyway. And you can heal them by restarting gdb.

> 
> It's not just regressions that are important. It's the fact that once qemu 
> has 
> your automatic switching hack it's impossible to make it work properly.

Interestingly, qemu used to work precisely like that before.

> 
>>>> There are internal issues in gdb (hard coupling of current and target
>>>> arch) that will not allow this to be fixed in the near future
>>> Really? I'm pretty sure other architectures already manage it.
>> What other archs are comparably weird like x86?
> 
> ARM has multiple instruction sets/cpu modes (and can mix the two within the 
> same process). PPC and MIPS also have something similar, though I'm not sure 
> how well they're supported by gdb.

Do those archs also have multiple register layouts that are coupled to
those different instruction sets? Do they switch the instruction sets
via 'set arch'? I think x86 is (historically) special here.

> 
> I suspect you may be approaching this the wrong way. Instead of trying to 
> switch architectures, you probably need to teach the 64-bit debugger how to 
> debug 32-bit code.

As I said, the problem in gdb is the hard coupling of the target
architecture (which could perfectly stay at x86_64 for a session) and
the current debugger architecture (which should be switched according to
the current CPU mode). Unfortunately, this is not yet feasible with gdb,
see gdbarch_update_p().

Fixing this (once understood what are all the problems preventing a fix
for several years now) is one thing, keeping the workaround for current
gdb in qemu is, IMHO, another. Right now we don't have a gdb fix in
sight, so I'm simply voting for reintroducing the workaround. That's
all. We can kill it or make it optional once the issue is solved. But we
should _not_ do this _before_ it is solved, causing only pain to people
who just want to use the gdbstub.

Jan

signature.asc
Description: OpenPGP digital signature