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

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

Jan