Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: cseo@linux.vnet.ibm.com (Carlos Eduardo Seo)
Cc: Ulrich.Weigand@de.ibm.com (Ulrich Weigand),
	        gdb-patches@sourceware.org (GDB Patches Mailing List)
Subject: Re: [RFC] Add support for PPC Altivec registers in gcore
Date: Mon, 26 Nov 2007 16:09:00 -0000	[thread overview]
Message-ID: <200711261609.lAQG9S5c005991@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <4748FF40.9080409@linux.vnet.ibm.com> from "Carlos Eduardo Seo" at Nov 25, 2007 02:51:12 AM

Carlos Eduardo Seo wrote:

> Ulrich Weigand wrote:
> >
> > Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> wrote on 11/06/2007
> > 02:42:43 PM:
> >
> > > I was taking a look at gdbarch.sh. Where's the "right" place to put
> > > the register list?
> >
> > In "function_list".   If you want to add a new data symbol, you'll
> > need type "v".  Best place is probably after regset_from_core_section.
> Do you think it's better to initialize this new structure with the
> registers names in gdbarch.c, or have it initialized in each
> arch-tdep.c file with the supported registers for that arch?

Maybe there is some misunderstanding: I was not talking about a list
of *register names*, rather a set of core file *section names*.

I'd suggest to define a data structure along the lines of:

struct core_regset_section
{
  const char *name;
  int len;
};

and then define arrays of those in the -tdep.c files, like:

static struct core_regset_section ppc_regset_sections[] =
{
  { ".reg", ... },
  { ".reg2", ... },
  { ".reg-vmx", ... },
  { NULL, 0 }
};


In gdbarch.sh, you'd then add an entry like:
v:struct core_regset_section *:core_regset_sections

which would generate functions
 gdbarch_core_regset_sections   and
 gdbarch_set_core_regset_sections


In the -tdep.c file, you'd now be able to install the array
defined above:

  gdbarch_set_core_regset_sections (gdbarch, ppc_regset_sections);

and in linux-nat.c, you'd be able to call gdbarch_core_regset_sections
to get at that list.

For platforms that do not override that gdbarch routine, you can
fall back to a default along the lines of

struct default_regset_sections[] = 
{
  { ".reg", sizeof (gdb_gregset_t) },
  { ".reg2", sizeof (gdb_fpregset_t) },
  { NULL, 0 }
};

Does this make sense?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


  reply	other threads:[~2007-11-26 16:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF67129E0D.852FADB2-ON4125738B.0050E74D-4125738B.005102FF@de.ibm.com>
2007-11-25  4:51 ` Carlos Eduardo Seo
2007-11-26 16:09   ` Ulrich Weigand [this message]
2007-11-26 16:12     ` Carlos Eduardo Seo
2007-10-26 22:14 Carlos Eduardo Seo
2007-10-29 19:24 ` Ulrich Weigand
2007-10-30 21:02   ` Carlos Eduardo Seo
2007-10-30 21:18     ` Ulrich Weigand
2007-10-30 21:30       ` Carlos Eduardo Seo
2007-10-30 21:31         ` Ulrich Weigand
2007-10-31 21:14           ` Carlos Eduardo Seo
2007-10-31 21:43             ` Ulrich Weigand
2008-02-08 21:42               ` Carlos Eduardo Seo
2008-02-18 18:42                 ` Ulrich Weigand
2008-02-27 17:07                   ` Carlos Eduardo Seo
2008-03-05 18:27                     ` Ulrich Weigand
2008-03-10 14:22                   ` Carlos Eduardo Seo
2008-03-17 19:07                     ` Ulrich Weigand
2008-03-20 15:31                       ` Carlos Eduardo Seo
2008-03-25 20:13                         ` Ulrich Weigand
2008-03-25 21:31                           ` Andreas Schwab
2008-03-25 21:54                             ` Ulrich Weigand
2008-03-25 22:46                               ` Carlos Eduardo Seo
2008-03-26 11:28                                 ` Ulrich Weigand
2008-03-27  1:52                       ` Carlos Eduardo Seo
2008-03-27  9:00                         ` Andreas Schwab
2008-03-27 19:54                         ` Ulrich Weigand
2008-03-28 20:41                           ` Carlos Eduardo Seo
2008-03-31 19:19                             ` Ulrich Weigand
2008-05-09 19:27                               ` Carlos Eduardo Seo
2008-05-09 20:30                                 ` Ulrich Weigand
2008-05-10  1:33                                   ` Carlos Eduardo Seo
2008-05-14  4:22                                     ` Ulrich Weigand
2008-05-20 18:41                                       ` Carlos Eduardo Seo
2008-05-21 18:46                                         ` Ulrich Weigand
2008-05-22 14:34                                           ` Carlos Eduardo Seo
2008-05-22 18:45                                             ` Ulrich Weigand
2008-05-26 16:26                                               ` Carlos Eduardo Seo

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=200711261609.lAQG9S5c005991@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cseo@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.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