Re: mode processor mode switch
John Baldwin <[email protected]> Fri, 17 Jan 2020 13:45:31 -0800
| Newsgroups | gmane.comp.gdb.devel,gmane.comp.gdb.general |
|---|---|
| Message-ID | <[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 descripti= on with the registers and types. >> >=20 > 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. --=20 John Baldwin