From: Simon Marchi <simon.marchi@polymtl.ca>
To: John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/9] Support fs_base and gs_base on FreeBSD/i386.
Date: Sat, 02 Feb 2019 15:26:00 -0000 [thread overview]
Message-ID: <c5f503bb49ed582a33e0b1b09e5f66eb@polymtl.ca> (raw)
In-Reply-To: <dd63aee602e301565ca6853c8c40d983bc39fb2c.1548180889.git.jhb@FreeBSD.org>
On 2019-01-22 13:42, John Baldwin wrote:
> The i386 BSD native target uses the same ptrace operations
> (PT_[GS]ET[FG]SBASE) as the amd64 BSD native target to fetch and store
> the registers.
>
> The amd64 BSD native now uses 'tdep->fsbase_regnum' instead of
> hardcoding AMD64_FSBASE_REGNUM and AMD64_GSBASE_REGNUM to support
> 32-bit targets. In addition, the store operations explicitly zero the
> new register value before fetching it from the register cache to
> ensure 32-bit values are zero-extended.
To be clear, this happens when debugging a 32-bits process on a 64-bits
OS? When debugging a 32-bits process on a 32-bits OS, the code in
i386-bsd-nat.c would be used?
> gdb/ChangeLog:
>
> * amd64-bsd-nat.c (amd64bsd_fetch_inferior_registers): Use
> tdep->fsbase_regnum instead of constants for fs_base and gs_base.
> (amd64bsd_store_inferior_registers): Likewise.
> * amd64-fbsd-nat.c (amd64_fbsd_nat_target::read_description):
> Enable segment base registers.
> * i386-bsd-nat.c (i386bsd_fetch_inferior_registers): Use
> PT_GETFSBASE and PT_GETGSBASE.
> (i386bsd_store_inferior_registers): Use PT_SETFSBASE and PT_SETGSBASE.
> * i386-fbsd-nat.c (i386_fbsd_nat_target::read_description): Enable
> segment base registers.
> * i386-fbsd-tdep.c (i386fbsd_core_read_description): Likewise.
> ---
> gdb/ChangeLog | 14 ++++++++++++
> gdb/amd64-bsd-nat.c | 26 ++++++++++++++-------
> gdb/amd64-fbsd-nat.c | 4 ++--
> gdb/i386-bsd-nat.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
> gdb/i386-fbsd-nat.c | 2 +-
> gdb/i386-fbsd-tdep.c | 2 +-
> 6 files changed, 90 insertions(+), 12 deletions(-)
>
> diff --git a/gdb/ChangeLog b/gdb/ChangeLog
> index 4afd5b664e..056a60fa23 100644
> --- a/gdb/ChangeLog
> +++ b/gdb/ChangeLog
> @@ -1,3 +1,17 @@
> +2019-01-22 John Baldwin <jhb@FreeBSD.org>
> +
> + * amd64-bsd-nat.c (amd64bsd_fetch_inferior_registers): Use
> + tdep->fsbase_regnum instead of constants for fs_base and gs_base.
> + (amd64bsd_store_inferior_registers): Likewise.
> + * amd64-fbsd-nat.c (amd64_fbsd_nat_target::read_description):
> + Enable segment base registers.
> + * i386-bsd-nat.c (i386bsd_fetch_inferior_registers): Use
> + PT_GETFSBASE and PT_GETGSBASE.
> + (i386bsd_store_inferior_registers): Use PT_SETFSBASE and
> PT_SETGSBASE.
> + * i386-fbsd-nat.c (i386_fbsd_nat_target::read_description): Enable
> + segment base registers.
> + * i386-fbsd-tdep.c (i386fbsd_core_read_description): Likewise.
> +
> 2019-01-22 John Baldwin <jhb@FreeBSD.org>
>
> * amd64-fbsd-nat.c (amd64_fbsd_nat_target::read_description):
> diff --git a/gdb/amd64-bsd-nat.c b/gdb/amd64-bsd-nat.c
> index a2a91abb91..0f47ff6c61 100644
> --- a/gdb/amd64-bsd-nat.c
> +++ b/gdb/amd64-bsd-nat.c
> @@ -43,6 +43,9 @@ amd64bsd_fetch_inferior_registers (struct regcache
> *regcache, int regnum)
> {
> struct gdbarch *gdbarch = regcache->arch ();
> pid_t pid = get_ptrace_pid (regcache->ptid ());
> +#ifdef PT_GETFSBASE
> + const struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +#endif
TDEP is used in both #ifdef PT_GETFSBASE and #ifdef PT_GETGSBASE, but is
only declared here in an #ifdef PT_GETFSBASE. I suppose it's not
actually an issue because they will always be present together. But we
might as well use "#if defined(PT_GETFSBASE) || defined(PT_GETGSBASE)"
for the declaration.
>
> if (regnum == -1 || amd64_native_gregset_supplies_p (gdbarch,
> regnum))
> {
> @@ -57,27 +60,27 @@ amd64bsd_fetch_inferior_registers (struct regcache
> *regcache, int regnum)
> }
>
> #ifdef PT_GETFSBASE
> - if (regnum == -1 || regnum == AMD64_FSBASE_REGNUM)
> + if (regnum == -1 || regnum == tdep->fsbase_regnum)
> {
> register_t base;
>
> if (ptrace (PT_GETFSBASE, pid, (PTRACE_TYPE_ARG3) &base, 0) ==
> -1)
> perror_with_name (_("Couldn't get segment register fs_base"));
>
> - regcache->raw_supply (AMD64_FSBASE_REGNUM, &base);
> + regcache->raw_supply (tdep->fsbase_regnum, &base);
> if (regnum != -1)
> return;
> }
> #endif
> #ifdef PT_GETGSBASE
> - if (regnum == -1 || regnum == AMD64_GSBASE_REGNUM)
> + if (regnum == -1 || regnum == tdep->fsbase_regnum + 1)
> {
> register_t base;
>
> if (ptrace (PT_GETGSBASE, pid, (PTRACE_TYPE_ARG3) &base, 0) ==
> -1)
> perror_with_name (_("Couldn't get segment register gs_base"));
>
> - regcache->raw_supply (AMD64_GSBASE_REGNUM, &base);
> + regcache->raw_supply (tdep->fsbase_regnum + 1, &base);
> if (regnum != -1)
> return;
> }
> @@ -116,6 +119,9 @@ amd64bsd_store_inferior_registers (struct regcache
> *regcache, int regnum)
> {
> struct gdbarch *gdbarch = regcache->arch ();
> pid_t pid = get_ptrace_pid (regcache->ptid ());
> +#ifdef PT_GETFSBASE
> + const struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +#endif
Same here.
>
> if (regnum == -1 || amd64_native_gregset_supplies_p (gdbarch,
> regnum))
> {
> @@ -134,11 +140,13 @@ amd64bsd_store_inferior_registers (struct
> regcache *regcache, int regnum)
> }
>
> #ifdef PT_SETFSBASE
> - if (regnum == -1 || regnum == AMD64_FSBASE_REGNUM)
> + if (regnum == -1 || regnum == tdep->fsbase_regnum)
> {
> register_t base;
>
> - regcache->raw_collect (AMD64_FSBASE_REGNUM, &base);
> + /* Clear the full base value to support 32-bit targets. */
> + base = 0;
> + regcache->raw_collect (tdep->fsbase_regnum, &base);
It's probably safer to clear the value to 0 as you did, so that's fine.
But I would have thought that when debugging 32-bits processes, the high
bits would be ignored at some point. The kernel would know that this is
a 32 bits register, so it would just take the 32 low bits of what it
receives, and it magically works whatever the original data type is
because it's little endian.
Otherwise, this LGTM.
Simon
next prev parent reply other threads:[~2019-02-02 15:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 18:43 [PATCH 0/9] Support for thread-local variables on FreeBSD John Baldwin
2019-01-22 18:43 ` [PATCH 1/9] Support the fs_base and gs_base registers on i386 John Baldwin
2019-01-27 4:22 ` Simon Marchi
2019-01-28 17:54 ` John Baldwin
2019-02-02 15:11 ` Simon Marchi
2019-01-22 18:43 ` [PATCH 9/9] Support TLS variables on FreeBSD/powerpc John Baldwin
2019-01-22 18:43 ` [PATCH 3/9] Handle TLS variable lookups when using separate debug object files John Baldwin
2019-02-02 15:52 ` Simon Marchi
2019-02-04 20:02 ` John Baldwin
2019-02-05 20:06 ` Simon Marchi
2019-02-05 22:21 ` John Baldwin
2019-02-05 22:33 ` John Baldwin
[not found] ` <67973931006085a171ad69952649de33@polymtl.ca>
2019-02-07 4:08 ` Simon Marchi
2019-01-22 18:43 ` [PATCH 7/9] Support TLS variables on FreeBSD/i386 John Baldwin
2019-01-22 18:43 ` [PATCH 2/9] Support fs_base and gs_base " John Baldwin
2019-02-02 15:26 ` Simon Marchi [this message]
2019-02-04 19:45 ` John Baldwin
2019-02-05 18:59 ` Simon Marchi
2019-01-22 18:43 ` [PATCH 6/9] Support TLS variables on FreeBSD/amd64 John Baldwin
2019-01-22 18:52 ` [PATCH 4/9] Add a new gdbarch method to resolve the address of TLS variables John Baldwin
2019-01-22 18:52 ` [PATCH 8/9] Support TLS variables on FreeBSD/riscv John Baldwin
2019-01-27 23:35 ` Andrew Burgess
2019-01-22 18:52 ` [PATCH 5/9] Add a helper function to resolve TLS variable addresses for FreeBSD John Baldwin
2019-01-24 17:09 ` John Baldwin
2019-02-07 5:05 ` Simon Marchi
2019-02-07 17:02 ` John Baldwin
2019-02-09 0:34 ` John Baldwin
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=c5f503bb49ed582a33e0b1b09e5f66eb@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=jhb@freebsd.org \
/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