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
next prev parent 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