mode processor mode switch

mode processor mode switch

[Jirka Koutný]

Hello,

I have a 32-bit elf executable which at some point switches to long mode
(kernel is 64-bit). Is there a way to tell gdb about the .code32/64
directives? Because expectedly the switch messes up disassembly and
stepping.

Thank you
Jirka

Re: mode processor mode switch

[Luis Machado]

Hi,

On 1/14/20 8:58 AM, Jirka Koutný wrote:
> Hello,
> 
> I have a 32-bit elf executable which at some point switches to long mode
> (kernel is 64-bit). Is there a way to tell gdb about the .code32/64
> directives? Because expectedly the switch messes up disassembly and
> stepping.
> 
> Thank you
> Jirka
> 

Unfortunately i don't think there is a good way to achieve this with the 
current implementation.

You could teach GDB about the quirks in the architecture, but it sounds 
better to have a more general solution.

I'm working on making this more flexible though, since i have a need to 
make the architecture information per-thread, at least the target 
description with the registers and types.

But no ETA yet.

Re: mode processor mode switch

[Pedro Alves]

On 1/16/20 2:51 PM, Luis Machado wrote:
> Hi,
> 
> On 1/14/20 8:58 AM, Jirka Koutný wrote:
>> Hello,
>>
>> I have a 32-bit elf executable which at some point switches to long mode
>> (kernel is 64-bit). Is there a way to tell gdb about the .code32/64
>> directives? Because expectedly the switch messes up disassembly and
>> stepping.
>>
>> Thank you
>> Jirka
>>
> 
> Unfortunately i don't think there is a good way to achieve this with the current implementation.
> 
> You could teach GDB about the quirks in the architecture, but it sounds better to have a more general solution.
> 
> I'm working on making this more flexible though, since i have a need to make the architecture information per-thread, at least the target description with the registers and types.
> 

For x86-64 in particular, I think the ideal solution would be for
the remote target to always report the widest mode it supports,
which would be 64-bit, and then do the 32-bit/16-bit modes
presentation all on the gdb side (i.e., user-visible 32-bit on
top of 64-bit description).  Mode switching would not change the remote
target description.  This is unlike the current architecture where a
remote server reports a 32-bit description for a 32-bit process even
if the remote server is actually running on a 64-bit machine.

Thanks,
Pedro Alves

Re: mode processor mode switch

[John Baldwin]

On 1/16/20 10:52 AM, Pedro Alves wrote:
> On 1/16/20 2:51 PM, Luis Machado wrote:
>> Hi,
>>
>> On 1/14/20 8:58 AM, Jirka Koutný wrote:
>>> Hello,
>>>
>>> I have a 32-bit elf executable which at some point switches to long mode
>>> (kernel is 64-bit). Is there a way to tell gdb about the .code32/64
>>> directives? Because expectedly the switch messes up disassembly and
>>> stepping.
>>>
>>> Thank you
>>> Jirka
>>>
>>
>> Unfortunately i don't think there is a good way to achieve this with the current implementation.
>>
>> You could teach GDB about the quirks in the architecture, but it sounds better to have a more general solution.
>>
>> I'm working on making this more flexible though, since i have a need to make the architecture information per-thread, at least the target description with the registers and types.
>>
> 
> For x86-64 in particular, I think the ideal solution would be for
> the remote target to always report the widest mode it supports,
> which would be 64-bit, and then do the 32-bit/16-bit modes
> presentation all on the gdb side (i.e., user-visible 32-bit on
> top of 64-bit description).  Mode switching would not change the remote
> target description.  This is unlike the current architecture where a
> remote server reports a 32-bit description for a 32-bit process even
> if the remote server is actually running on a 64-bit machine.

I think this is the way to go, but you might still need some way to specify
the mode.  I'm not quite sure what qemu does, but for a gdb stub I've
worked on for bhyve (a KVM-like hypervisor in FreeBSD), it always reports
the architecture as 64-bits but checks various control registers when
resolving virtual addresses for the 'm' and 'M' protocol commands.

-- 
John Baldwin

Re: mode processor mode switch

[Jirka Koutný]

Erm hey guys, thanks for all your responses. I found out that it works if
instead of inline assembly I just make a separate .S file and compile with
'as -m32 -g' and then link with gcc.

fre. 17. jan. 2020 kl. 21:45 skrev John Baldwin <jhb@freebsd.org>:

> On 1/16/20 10:52 AM, Pedro Alves wrote:
> > On 1/16/20 2:51 PM, Luis Machado wrote:
> >> Hi,
> >>
> >> On 1/14/20 8:58 AM, Jirka Koutný wrote:
> >>> Hello,
> >>>
> >>> I have a 32-bit elf executable which at some point switches to long
> mode
> >>> (kernel is 64-bit). Is there a way to tell gdb about the .code32/64
> >>> directives? Because expectedly the switch messes up disassembly and
> >>> stepping.
> >>>
> >>> Thank you
> >>> Jirka
> >>>
> >>
> >> Unfortunately i don't think there is a good way to achieve this with
> the current implementation.
> >>
> >> You could teach GDB about the quirks in the architecture, but it sounds
> better to have a more general solution.
> >>
> >> I'm working on making this more flexible though, since i have a need to
> make the architecture information per-thread, at least the target
> description with the registers and types.
> >>
> >
> > For x86-64 in particular, I think the ideal solution would be for
> > the remote target to always report the widest mode it supports,
> > which would be 64-bit, and then do the 32-bit/16-bit modes
> > presentation all on the gdb side (i.e., user-visible 32-bit on
> > top of 64-bit description).  Mode switching would not change the remote
> > target description.  This is unlike the current architecture where a
> > remote server reports a 32-bit description for a 32-bit process even
> > if the remote server is actually running on a 64-bit machine.
>
> I think this is the way to go, but you might still need some way to specify
> the mode.  I'm not quite sure what qemu does, but for a gdb stub I've
> worked on for bhyve (a KVM-like hypervisor in FreeBSD), it always reports
> the architecture as 64-bits but checks various control registers when
> resolving virtual addresses for the 'm' and 'M' protocol commands.
>
> --
> John Baldwin
>