[Top][All Lists]

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

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

From: Jan Kiszka
Subject: Re: [Qemu-devel] Re: [PATCH v5 18/18] gdbstub: x86: Switch 64/32 bit registers dynamically
Date: Wed, 19 Nov 2008 00:38:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

Paul Brook wrote:
> On Tuesday 18 November 2008, Jan Kiszka wrote:
>> Paul Brook wrote:
>>>> 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.
>>> I'm pretty sure all the infrastructure is there. gdb is able to natively
>>> debug 32-bit binaries on a 64-bit host and is able to switch disassembler
>>> modes for ARM vs. Thumb.
>> How is it done on ARM? Maybe that will provide the right pointer for x86.
> Anything you have symbols for you know what type of code it is from the 
> binary. On ARM there's an EABI defined scheme for identifying arm/thumb/data 
> regions. On x86 the ELF class of the image is probably sufficient.

ELF-based detection can only work as good the underlying 'raw' switching

> 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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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