Pass gdbarch, not regset, to supply regset et.al.?

Pass gdbarch, not regset, to supply regset et.al.?

[Andrew Cagney]

Mark,

I'm wondering if it would be easier to explicitly pass the gdbarch 
instead of the regset to the regset function?

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?

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);
...
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?

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.

Andrew

Re: Pass gdbarch, not regset, to supply regset et.al.?

[Mark Kettenis]

   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.

   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.

   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++ ;-).

   ...
   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?

   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.

Mark

Re: Pass gdbarch, not regset, to supply regset et.al.?

[Andrew Cagney]

>    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

Re: Pass gdbarch, not regset, to supply regset et.al.?

[Mark Kettenis]

   Date: Wed, 19 Nov 2003 18:28:29 -0500
   From: Andrew Cagney <cagney@gnu.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.

Yes they do, but:

* It's a bit of a hassle to get at the right architecture from within
  a *-nat.c module.

* There are cases where there are several implied architectures to
  choose from.

* What's the implied architecture of an architecture-independent
  remote protocol?  I'd like to make these register sets work for
  remote protocols too, without havong to associate some sort og
  "generic" gdbarch with it.

   > 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?

There might be too much generality, but that's certainly better than
too little generality.  I've defenitely got the feeling that gdbarch
gives us too little generality.

Mark

Re: Pass gdbarch, not regset, to supply regset et.al.?

[Andrew Cagney]

> * It's a bit of a hassle to get at the right architecture from within
>   a *-nat.c module.

(it's a bit of a hassle more generally too :-) target->lwp->architecture?

> * There are cases where there are several implied architectures to
>   choose from.
> * What's the implied architecture of an architecture-independent
>   remote protocol?  I'd like to make these register sets work for
>   remote protocols too, without havong to associate some sort og
>   "generic" gdbarch with it.

>    > 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?
> 
> There might be too much generality, but that's certainly better than
> too little generality.  I've defenitely got the feeling that gdbarch
> gives us too little generality.

(Think yourself lucky.  At one stage people were arguing that the 
architecture and target vector should be combined into a single 
monolythic mess :-().

"regsets" could be made more independant of gdbarch by having its own 
local table and search methods:
	add_corefile_regset (bfd_arch, mach, size, name, ..., method);
	corefile_regset (bfd_arch, mach, name, size)
and a wrapper:
	gdbarch_corefile_regset (gdbarch, name, size)
	-> corefile_regset (gdbarch->bfd_arch, name, size)

Anyway, how were you thinking of doing things for the sparc?

Andrew