qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH v5 18/18] gdbstub: x86: Switch 64/32 bit registers dynamically
Date: Tue, 18 Nov 2008 23:37:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]