Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andreas Arnez <arnez@linux.vnet.ibm.com>
To: lgustavo@codesourcery.com
Cc: gdb-patches@sourceware.org, Ulrich Weigand <uweigand@de.ibm.com>
Subject: Re: [PATCH 3/3] Dynamic core regset sections support
Date: Fri, 07 Jun 2013 16:40:00 -0000	[thread overview]
Message-ID: <87hah9ub6h.fsf@br87z6lw.de.ibm.com> (raw)
In-Reply-To: <51B1F195.70008@codesourcery.com> (Luis Machado's message of	"Fri, 07 Jun 2013 16:43:33 +0200")

Luis Machado <lgustavo@codesourcery.com> writes:

> Just a general thought. If a core file section must not always be
> generated, would it make more sense to use dynamic section information
> for s390 instead of forcing all the other targets to use a mechanism
> that is not required for them?

The reason for removing the old interface was to avoid increasing the
number of gdbarch interfaces for this.  In addition, the change reduces
the amount of target-dependent code for most targets, which I consider
beneficial.

> I'm not necessarily against this modification, but i was wondering
> about other options.

Sure, I'm open for suggestions.

> Did you maybe forget to handle ppc64 core file sections in this
> change?

Phew, you're right.  I guess we can use tdep->wordsize instead, like
this (right?):

  if ((*cb) (".reg", 48 * tdep->wordsize, "general-purpose", cb_data))

It would be great if you could verify this change -- I'm providing an
updated patch below.

> Another general comment/suggestion. Removing static definitions of
> core file register sets and replacing them with hardcoded arguments
> for a pointer-based call to a callback function seems to
> scramble/confuse things a little.
>
> It may be nicer to keep the static definitions around, but iterate
> through them in the new iterator function. What do you think?

I thought about something like that as well.  However, my implementation
attempt didn't result in less (or simpler) code.

Updated patch for linux-tdep.c:

--- a/gdb/ppc-linux-tdep.c
+++ b/gdb/ppc-linux-tdep.c
@@ -256,53 +256,26 @@ ppc_linux_return_value (struct gdbarch *gdbarch, struct value *function,
 				      readbuf, writebuf);
 }
 
-static struct core_regset_section ppc_linux_vsx_regset_sections[] =
-{
-  { ".reg", 48 * 4, "general-purpose" },
-  { ".reg2", 264, "floating-point" },
-  { ".reg-ppc-vmx", 544, "ppc Altivec" },
-  { ".reg-ppc-vsx", 256, "POWER7 VSX" },
-  { NULL, 0}
-};
-
-static struct core_regset_section ppc_linux_vmx_regset_sections[] =
-{
-  { ".reg", 48 * 4, "general-purpose" },
-  { ".reg2", 264, "floating-point" },
-  { ".reg-ppc-vmx", 544, "ppc Altivec" },
-  { NULL, 0}
-};
-
-static struct core_regset_section ppc_linux_fp_regset_sections[] =
-{
-  { ".reg", 48 * 4, "general-purpose" },
-  { ".reg2", 264, "floating-point" },
-  { NULL, 0}
-};
-
-static struct core_regset_section ppc64_linux_vsx_regset_sections[] =
-{
-  { ".reg", 48 * 8, "general-purpose" },
-  { ".reg2", 264, "floating-point" },
-  { ".reg-ppc-vmx", 544, "ppc Altivec" },
-  { ".reg-ppc-vsx", 256, "POWER7 VSX" },
-  { NULL, 0}
-};
-
-static struct core_regset_section ppc64_linux_vmx_regset_sections[] =
-{
-  { ".reg", 48 * 8, "general-purpose" },
-  { ".reg2", 264, "floating-point" },
-  { ".reg-ppc-vmx", 544, "ppc Altivec" },
-  { NULL, 0}
-};
-
-static struct core_regset_section ppc64_linux_fp_regset_sections[] =
+static void
+ppc_linux_iterate_over_regset_sections (struct gdbarch *gdbarch,
+					 iterate_over_regset_sections_cb *cb,
+					 void *cb_data,
+					 const struct regcache *regcache)
 {
-  { ".reg", 48 * 8, "general-purpose" },
-  { ".reg2", 264, "floating-point" },
-  { NULL, 0}
-};
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  int have_vsx = tdep->ppc_vr0_regnum != -1;
+  int have_altivec = tdep->ppc_vsr0_upper_regnum != -1;
+
+  if ((*cb) (".reg", 48 * tdep->wordsize, "general-purpose", cb_data))
+    return;
+  if ((*cb) (".reg2", 264, "floating-point", cb_data))
+    return;
+  if (have_altivec)
+    if ((*cb) (".reg-ppc-vmx", 544, "ppc Altivec", cb_data))
+      return;
+  if (have_vsx)
+    (*cb) (".reg-ppc-vsx", 256, "POWER7 VSX", cb_data);
+}
 
 /* PLT stub in executable.  */
 static struct ppc_insn_pattern powerpc32_plt_stub[] =
@@ -1305,18 +1278,9 @@ ppc_linux_init_abi (struct gdbarch_info info,
       else
 	set_gdbarch_gcore_bfd_target (gdbarch, "elf32-powerpc");
 
-      /* Supported register sections.  */
-      if (tdesc_find_feature (info.target_desc,
-			      "org.gnu.gdb.power.vsx"))
-	set_gdbarch_core_regset_sections (gdbarch,
-					  ppc_linux_vsx_regset_sections);
-      else if (tdesc_find_feature (info.target_desc,
-			       "org.gnu.gdb.power.altivec"))
-	set_gdbarch_core_regset_sections (gdbarch,
-					  ppc_linux_vmx_regset_sections);
-      else
-	set_gdbarch_core_regset_sections (gdbarch,
-					  ppc_linux_fp_regset_sections);
+      /* Iterator for supported register sections.  */
+      set_gdbarch_iterate_over_regset_sections
+	(gdbarch, ppc_linux_iterate_over_regset_sections);
 
       if (powerpc_so_ops.in_dynsym_resolve_code == NULL)
 	{
@@ -1360,18 +1324,9 @@ ppc_linux_init_abi (struct gdbarch_info info,
       else
 	set_gdbarch_gcore_bfd_target (gdbarch, "elf64-powerpc");
 
-      /* Supported register sections.  */
-      if (tdesc_find_feature (info.target_desc,
-			      "org.gnu.gdb.power.vsx"))
-	set_gdbarch_core_regset_sections (gdbarch,
-					  ppc64_linux_vsx_regset_sections);
-      else if (tdesc_find_feature (info.target_desc,
-			       "org.gnu.gdb.power.altivec"))
-	set_gdbarch_core_regset_sections (gdbarch,
-					  ppc64_linux_vmx_regset_sections);
-      else
-	set_gdbarch_core_regset_sections (gdbarch,
-					  ppc64_linux_fp_regset_sections);
+      /* Iterator for supported register sections.  */
+      set_gdbarch_iterate_over_regset_sections
+	(gdbarch, ppc_linux_iterate_over_regset_sections);
     }
 
   /* PPC32 uses a different prpsinfo32 compared to most other Linux


  reply	other threads:[~2013-06-07 16:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-07 13:44 [RFA/RFT PATCH 0/3] Add TDB regset support Andreas Arnez
2013-06-07 13:50 ` [PATCH 1/3] S/390 regmap rework Andreas Arnez
2015-05-05 19:17   ` Regression on gdb.base/checkpoint.exp on S/390 (was: Re: [PATCH 1/3] S/390 regmap rework) Sergio Durigan Junior
2015-05-06 18:16     ` Regression on gdb.base/checkpoint.exp on S/390 Andreas Arnez
2013-06-07 13:51 ` [PATCH 2/3] Add TDB regset Andreas Arnez
2013-06-07 13:53 ` [PATCH 3/3] Dynamic core regset sections support Andreas Arnez
2013-06-07 14:43   ` Luis Machado
2013-06-07 16:40     ` Andreas Arnez [this message]
2013-06-07 15:03 ` [RFA/RFT PATCH 0/3] Add TDB regset support Pedro Alves
2013-06-07 15:59   ` Andreas Arnez
2013-06-07 16:44     ` Pedro Alves
2013-06-07 18:16       ` Andreas Arnez
2013-06-07 19:06         ` Pedro Alves
2013-06-10 16:59           ` Andreas Arnez
2013-06-11 10:48             ` Pedro Alves

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=87hah9ub6h.fsf@br87z6lw.de.ibm.com \
    --to=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=lgustavo@codesourcery.com \
    --cc=uweigand@de.ibm.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