From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2YO6-0006RJ-KO for qemu-devel@nongnu.org; Tue, 18 Nov 2008 16:45:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L2YO4-0006R7-6e for qemu-devel@nongnu.org; Tue, 18 Nov 2008 16:45:33 -0500 Received: from [199.232.76.173] (port=40632 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2YO4-0006R4-16 for qemu-devel@nongnu.org; Tue, 18 Nov 2008 16:45:32 -0500 Received: from an-out-0708.google.com ([209.85.132.251]:30924) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L2YO4-00080Q-37 for qemu-devel@nongnu.org; Tue, 18 Nov 2008 16:45:32 -0500 Received: by an-out-0708.google.com with SMTP id c38so1234565ana.37 for ; Tue, 18 Nov 2008 13:45:30 -0800 (PST) Message-ID: <49233776.9050504@codemonkey.ws> Date: Tue, 18 Nov 2008 15:45:26 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v5 18/18] gdbstub: x86: Switch 64/32 bit registers dynamically References: <20081117161857.26880.45423.stgit@mchn012c.ww002.siemens.net> <20081117161859.26880.70678.stgit@mchn012c.ww002.siemens.net> <492334B9.3010705@codemonkey.ws> In-Reply-To: <492334B9.3010705@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jan Kiszka , Paul Brook 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? 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. Regards, Anthony Liguori > Regards, > > Anthony Liguori > > >> >> >