Anthony Liguori wrote:
> Anthony Liguori wrote:
>> Jan Kiszka wrote:
>>> Commit 5459 broke gdbstub's dynamic register set switching between
>>> x86-64 and i386. That prevents setting the correct architecture in gdb
>>> when debugging 32 or 16-bit code in a 64-bit emulator. This patch
>>> reintroduces the feature over previous refactorings.
>>>   
>>
>> How does this interact with SMP?  If you have one VCPU in 32-bit mode
>> and another in 64-bit mode, won't that confuse GDB?

Each mode switch already confuses GDB: Either you see borken disassembly
and are unable to match what you see with your source code, or you
manually have to issue 'set arch ...' when you switch between CPUs in
different addressing modes. Fortunately, the latter is not a very common
case, at least to my experience.

The best approach, definitely, would be to teach GDB how to switch the
disassembler mode depending on the thread's (or VCPUs) state. But so
there is neither a mechanism in GDB for this, nor is GDB even aware of
the x86 modes (no tracking of privileged registers). We have some
preliminary patches for this, but they are still far away from GDB mainline.

> 
> After talking to Paul in IRC, it seems that GDB is going to make
> assumptions that all threads share an address space and potentially
> cache memory accesses or at least be sloppy with how it does memory
> accesses.
> 
> I think this is a pretty strong argument for using fork instead of
> threads.  I would think you should be able to provoke this pretty easily
> with an SMP guest.

As I explained in another reply, this is not the primary use case for
the gdbstub as I see it. However, I'm open to learn how fork could help
us while keeping the usability we now have via threads plus opening more
of the guest code for this kind of debugging (though I don't see a need
for the latter - yet).

Jan