Re: mode processor mode switch

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 <[email protected]>:

> 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=C3=BD 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 speci=
fy
> 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
>