From: "Jirka Koutný" <koutnji2@gmail.com>
To: John Baldwin <jhb@freebsd.org>
Cc: Pedro Alves <palves@redhat.com>,
Luis Machado <luis.machado@linaro.org>,
gdb@gnu.org
Subject: Re: mode processor mode switch
Date: Tue, 21 Jan 2020 12:56:00 -0000 [thread overview]
Message-ID: <CAH5nFm_kSg=ySGpS7pMcbacNmH_dqRnfnoK8qjhW0bB=MqjHeg@mail.gmail.com> (raw)
In-Reply-To: <a7160055-db0e-5fab-d48e-a1d83cfd1b01@FreeBSD.org>
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
>
prev parent reply other threads:[~2020-01-21 12:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 11:59 Jirka Koutný
2020-01-16 14:52 ` Luis Machado
2020-01-16 18:52 ` Pedro Alves
2020-01-17 21:46 ` John Baldwin
2020-01-21 12:56 ` Jirka Koutný [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH5nFm_kSg=ySGpS7pMcbacNmH_dqRnfnoK8qjhW0bB=MqjHeg@mail.gmail.com' \
--to=koutnji2@gmail.com \
--cc=gdb@gnu.org \
--cc=jhb@freebsd.org \
--cc=luis.machado@linaro.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox