Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org,
	Simon Marchi <simon.marchi@polymtl.ca>,
	Phil Muldoon <pmuldoon@redhat.com>
Subject: Re: [PATCH 1/2] Include the fs_base and gs_base registers in amd64 target descriptions.
Date: Thu, 13 Jul 2017 18:40:00 -0000	[thread overview]
Message-ID: <9fcc9ea0-da6b-10fa-8a8e-022aa82893c9@redhat.com> (raw)
In-Reply-To: <86y3rsp991.fsf@gmail.com>

On 07/13/2017 05:55 PM, Yao Qi wrote:

> because each tdesc_reg is a singleton among the target description.  The
> reason Simon observed that we have different "fs_base" tdesc_reg added
> and removed from the hash table is that they are from different target
> descriptions.  GDB crashes in tdesc_use_registers.  The arguments tdesc
> and tdesc_data are not consistent, tdesc is amd64 linux target
> description, but tdesc_data was got when tdesc is amd64 target
> description, so the tdesc_reg in tdesc_data are from amd64 target
> description as well.  So, we push a "fs_base" from one target
> description and want to remove a "fs_base" from another target
> description.
> 
> Does this answer your question?  I think maybe there is some "better"
> fix that is to keep tdesc and tdes_data consistent.  However, I don't
> think it further.  Since current GDB trunk is unusable on x86_64-linux,
> it is better get a fix soon.

Yeah.  It seems to me that the problem is that
amd64_linux_init_abi uses amd64_init_abi as helper, but
they don't coordinate on which fallback tdesc to use.

So amd64_init_abi does:

  if (! tdesc_has_registers (tdesc))
    tdesc = tdesc_amd64;

and creates a register in the "tdesc_amd64" architecture.

and then after, amd64_linux_init_abi does:

  if (! tdesc_has_registers (tdesc))
    tdesc = tdesc_amd64_linux;
  tdep->tdesc = tdesc;

But when amd64_init_abi is being called as helper, it should
fallback to tdesc_amd64_linux instead.

Notice that amd64_linux_init_abi also calls tdesc_numbered_register,
for orig_rax.  So if some other foo_init_abi routine would use 
amd64_linux_init_abi as helper, then that tdesc_numbered_register call
would be problematic in the same way.

It seems to me that the proper fix is to make sure
that amd64_linux_init_abi and amd64_init_abi agree.  Something like
this patch below.  Fixes the crash for me.

From d5775b549291675d9bb5c095b837eca16733aa61 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Thu, 13 Jul 2017 19:09:13 +0100
Subject: [PATCH] fix

---
 gdb/amd64-linux-tdep.c |  9 +++------
 gdb/amd64-tdep.c       | 16 ++++++++--------
 gdb/amd64-tdep.h       |  5 ++++-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c
index 4ef0f78..7863d58 100644
--- a/gdb/amd64-linux-tdep.c
+++ b/gdb/amd64-linux-tdep.c
@@ -1863,7 +1863,6 @@ static void
 amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
-  const struct target_desc *tdesc = info.target_desc;
   struct tdesc_arch_data *tdesc_data
     = (struct tdesc_arch_data *) info.tdep_info;
   const struct tdesc_feature *feature;
@@ -1875,15 +1874,13 @@ amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
   tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
   tdep->sizeof_gregset = 27 * 8;
 
-  amd64_init_abi (info, gdbarch);
+  amd64_init_abi (info, gdbarch, tdesc_amd64_linux);
+
+  const target_desc *tdesc = tdep->tdesc;
 
   /* Reserve a number for orig_rax.  */
   set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
 
-  if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_amd64_linux;
-  tdep->tdesc = tdesc;
-
   feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
   if (feature == NULL)
     return;
diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
index 9ff7dfc..de89f95 100644
--- a/gdb/amd64-tdep.c
+++ b/gdb/amd64-tdep.c
@@ -3005,7 +3005,8 @@ static const int amd64_record_regmap[] =
 };
 
 void
-amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch,
+		target_desc *default_tdesc)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
   const struct target_desc *tdesc = info.target_desc;
@@ -3022,7 +3023,11 @@ amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
   tdep->fpregset = &amd64_fpregset;
 
   if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_amd64;
+    {
+      if (default_tdesc == NULL)
+	default_tdesc = tdesc_amd64;
+      tdesc = default_tdesc;
+    }
   tdep->tdesc = tdesc;
 
   tdep->num_core_regs = AMD64_NUM_GREGS + I387_NUM_REGS;
@@ -3199,13 +3204,8 @@ void
 amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
-  const struct target_desc *tdesc = info.target_desc;
 
-  amd64_init_abi (info, gdbarch);
-
-  if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_x32;
-  tdep->tdesc = tdesc;
+  amd64_init_abi (info, gdbarch, tdesc_x32);
 
   tdep->num_dword_regs = 17;
   set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
diff --git a/gdb/amd64-tdep.h b/gdb/amd64-tdep.h
index 87f0ba3..9f946af 100644
--- a/gdb/amd64-tdep.h
+++ b/gdb/amd64-tdep.h
@@ -97,7 +97,10 @@ extern void amd64_displaced_step_fixup (struct gdbarch *gdbarch,
 					CORE_ADDR from, CORE_ADDR to,
 					struct regcache *regs);
 
-extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+extern void amd64_init_abi (struct gdbarch_info info,
+			    struct gdbarch *gdbarch,
+			    target_desc *default_tdesc = NULL);
+
 extern void amd64_x32_init_abi (struct gdbarch_info info,
 				struct gdbarch *gdbarch);
 extern const struct target_desc *amd64_target_description (uint64_t xcr0);
-- 
2.5.5



  parent reply	other threads:[~2017-07-13 18:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 22:50 [PATCH 0/2] Support fs_base and gs_base for native FreeBSD/amd64 John Baldwin
2017-06-27 22:51 ` [PATCH 2/2] Support the fs_base and gs_base registers on FreeBSD/amd64 native processes John Baldwin
2017-07-11  8:09   ` Yao Qi
2017-06-27 22:51 ` [PATCH 1/2] Include the fs_base and gs_base registers in amd64 target descriptions John Baldwin
2017-07-11  8:03   ` Yao Qi
2017-07-11 16:26     ` John Baldwin
2017-07-12 12:16     ` Phil Muldoon
     [not found]       ` <CAH=s-PPM7u=f=_4k+=wLvv4z822VJRqbkxrsSv9C0eKqX-tMCA@mail.gmail.com>
2017-07-12 13:51         ` Simon Marchi
2017-07-12 20:03           ` John Baldwin
2017-07-13 16:55             ` Yao Qi
2017-07-13 17:04               ` John Baldwin
2017-07-13 18:40               ` Pedro Alves [this message]
2017-07-13 19:59                 ` Pedro Alves
2017-07-12 16:23         ` Keith Seitz
2017-07-11  7:49 ` [PATCH 0/2] Support fs_base and gs_base for native FreeBSD/amd64 Yao Qi
2017-07-11 16:26   ` 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=9fcc9ea0-da6b-10fa-8a8e-022aa82893c9@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@freebsd.org \
    --cc=pmuldoon@redhat.com \
    --cc=qiyaoltc@gmail.com \
    --cc=simon.marchi@polymtl.ca \
    /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