Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Mark Kettenis <kettenis@chello.nl>
Cc: ac131313@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: Pass gdbarch, not regset, to supply regset et.al.?
Date: Wed, 19 Nov 2003 23:28:00 -0000	[thread overview]
Message-ID: <3FBBFC9D.9080300@gnu.org> (raw)
In-Reply-To: <200311192144.hAJLixCZ000337@elgar.kettenis.dyndns.org>

>    Date: Wed, 19 Nov 2003 14:37:58 -0500
>    From: Andrew Cagney <ac131313@redhat.com>
> 
>    Mark,
> 
>    I'm wondering if it would be easier to explicitly pass the gdbarch 
>    instead of the regset to the regset function?
> 
> I've thought about that, but I don't think so.  I'd like to use these
> register sets even for cases where there's no gdbarch that we can
> easily get at.  I'm thinking specifically about the *-nat.c modules
> where register sets are provided by ptrace(2), /proc, etc.

Sorry, I'm lost.  ptrace and /proc both have an implied architecture, or 
at least OS.

>    At present the lookup regset code does this:
> 
> 	      tdep->gregset = XMALLOC (struct regset);
> 	      tdep->gregset->descr = tdep;
> 	      tdep->gregset->supply_regset = i386_supply_gregset;
> 
>    so that the architecture is tunneled through to the regset function.
> 
>       const struct gdbarch_tdep *tdep = regset->descr;
>       ...
>       for (i = 0; i < tdep->gregset_num_regs; i++)
> 
>    I'm wondering if it would be easier to just pass the architecture?
> 
> Well, you can always pass gdbarch as the description.  The point is
> that the current implementation makes it possible to pass in something
> that isn't related to a gdbarch at all.  I also think it doesn't
> necessarily make sense to copy the i386 implementation.  For SPARC I'm
> already thinking about a somewhat different implementation.

Will anyone every actually do this, or have we ended up with too much 
generality?

>    At the same time, I'm wondering if i386_regset_from_core_section should 
>    be abstracted a little so that, like reggroups it was set up:
> 
>    set_regset_supply_core_section (arch, ".reg", size, i386_supply_regset);
>    set_regset_supply_core_section (arch, ".reg2", i386_supply_fpregset);
> 
> Hey, since when is GDB is written in C++ ;-).

shhhh

>    ...
>    f = regset_supply_from_core_section (core_arch, ".name", length);
>    f (core_arch, current_regcache, regnum, contents, length);
>    ... or even the short cut ...
>    regset_supply_core_section (core_arch, ".name", current_regcache, 
>    regnum, contents, length);
> 
>    Thoughts?
> 
> Well, your set_regset_supply_core_section proposal makes it a bit
> awkward to override a particular core section defenition for a
> specific target.  Suppose that I have a generic i386 implementation
> for say ".reg" sections which I want to override for GNU/Hurd?

set_regset_core_section (arch, ".reg", size, i386_collect_gregset)
... then later ...
set_regset_core_section (arch, ".reg", size, gnuhurd_collect_gregset)?

>    I just came across this bit of PPC64 GNU/Linux code
> 
>    > void
>    > ppc_linux_supply_gregset (char *buf)
>    > {
>    >   int regi;
>    >   struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); 
>    > 
>    >   for (regi = 0; regi < 32; regi++)
>    >     supply_register (regi, buf + 4 * regi);
> 
>    (yes, that's a "4" not "8") and was studying the new mechanism.
> 
> It might pay to study the other PPC and PPC64 OS'es to see whether
> they could share an implementation.

True.

Andrew



  reply	other threads:[~2003-11-19 23:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-19 19:38 Andrew Cagney
2003-11-19 21:45 ` Mark Kettenis
2003-11-19 23:28   ` Andrew Cagney [this message]
2003-11-21 15:31     ` Mark Kettenis
2003-11-21 18:39       ` Andrew Cagney

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=3FBBFC9D.9080300@gnu.org \
    --to=cagney@gnu.org \
    --cc=ac131313@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@chello.nl \
    /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