Re: Register group proposal

Re: Register group proposal

[Stephane Carrez]

Hi!

>
>On an architecture with a large register set, GDBtk's register window can
>be difficult to read and slow to update.  Users can customize the window
>to hide individual registers, but that's a tedious procedure.
>

Yes. It really makes sense.

For ChorusOS, we have this notion of 'grouping'.  The DebugAPI allows
to retrieve all registers of a given group.  Until now, we have defined
three groups (could define more):

 - general registers (ie, r0..r31, eax, ...)
 - floating point registers (ie, f0,...)
 - specific registers (ie, sprg0, dbat, cr0, ...)

In most cases, you are interested to look at general registers or floating
point regs.  Less often, you will need to display the specific registers.


It would be interesting then to take the 'grouping' into account by
the new/next register API. The current semantics of `to_fetch_registers()'
when a -1 is passed is to fetch all registers. You can see that as
a group of all registers. I think it's then necessary to clarify or
extend this semantics.

The goal is that if someone asks for the general registers, we don't
have to fetch the specific/floating point registers.

Well, this is very close to a previous discussion about optimizing
the fetch of registers within all GDB sources (frame, backtrace, locals, ...)

>
>The CLI "info registers" command already accepts a register name as an
>optional paramter.  It could be extended to try that parameter as a group
>name first and a register name second, so e.g. "info registers float"
>would display all floating-point registers.
>
>What do you think?
>
>Nick

It's great if a given platform could define its own groups of registers
and that they are recognized by Insight after that.

What about plugging the grouping in your regs_init_*() functions?

	Stephane

-	-	-	-	-	-	-	-	-	-
Stephane |Sun Microsystems			|
 Carrez	 |Network Service Provider Division	| http://www.sun.com
	 |6 avenue Gustave Eiffel		|
	 |F-78182, St-Quentin-en-Yvelines-Cedex |

email: Stephane.Carrez@France.Sun.COM

Re: Register group proposal

[Nick Duffek]

On 21-Feb-2001, Stephane Carrez wrote:

>It would be interesting then to take the 'grouping' into account by
>the new/next register API. The current semantics of `to_fetch_registers()'
>when a -1 is passed is to fetch all registers. You can see that as
>a group of all registers. I think it's then necessary to clarify or
>extend this semantics.

I like that idea.

>What about plugging the grouping in your regs_init_*() functions?

Yes, I'll do that.

Nick

Re: Register group proposal

[Andrew Cagney]

> It would be interesting then to take the 'grouping' into account by
> the new/next register API. The current semantics of `to_fetch_registers()'
> when a -1 is passed is to fetch all registers. You can see that as
> a group of all registers. I think it's then necessary to clarify or
> extend this semantics.

(Assuming I understand Nick's proposal correctly) The groupings apply to
a frame, they don't apply to the raw register cache - the two should be
kept separate.

Too follow up an earlier posting, the only interface between frame and
frame registers and the raw register cache (ignoring async) would be
something like:

	read_rawreg (cache, rawnum, buf);
	write_rawreg (cache, rawnum, buf);

where RAWNUM shouldn't be confused with a FRAME's REGNUM.

As for tuning register performance.  Think of the raw register cache
just like a CPU cache.  If you get a request to fetch register FOO, then
there is likely benefit in also fetching registers adjacent to FOO.  If
your target is asynchronous (yes OK and GDB is event driven :-), then it
would also be free to quietly continue to fetch FOO related registers
long after the value for FOO has been supplied.

To give examples:

For Chorus, if you were given a request for what you know is a raw
floating point register then you might implement it using a call to
``floating point registers (ie, f0,...)'' and supply all of them.

For a remote target, remote.c might send down a ``G<base>:<bound>'' to
get a block of bytes from the register buffer (a packet extenstion) OR
it might request one register ``P<num>'' (a packet extension) and get
back a bunch of registers (much like the existing ``T'' reply can do
now''.

	Andrew

RE: Register group proposal

[Bernard Dautrevaux]

> -----Original Message-----
> From: Jim Kleck [ mailto:jim.kleck@NetergyNet.COM ]
> Sent: Tuesday, February 27, 2001 7:32 PM
> To: Andrew Cagney
> Cc: Nick Duffek; Dautrevaux@microprocess.com; gdb@sources.redhat.com;
> insight@sources.redhat.com
> Subject: Re: Register group proposal
> 
> 
> A consistent interface is *one* reason to have a particular interface.
> However, it is not the only thing to consider, nor have the "style
> advantages and disadvantages" been fully explored... at least not
> in this forum.
> 
> I would note that "struct blah *" is NOT fully opaque. Its 
> very use implies
> a control structure of some sort, and it is quite different 
> from the standard
> types provided by the language. Thus it is not using the full 
> "extensability"
> of the language.
> 
> An alternative I have not seen discussed is to have "typedef 
> void * blah"
> as the public interface (then the implementation would need to cast
> the object to the internal representation before operating on it).
> 
> Finally, in the "LONGEST" example, why replace "a = b + c;" with
> "a = add(b, c);". My inclination would be to overload the "+" so that
> no change to the users of the type are necessary.
> 

I'm afraid GDB is written in C isn't it? so overloading '+' is not really an
option. 

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

RE: Register group proposal

[Bernard Dautrevaux]

> -----Original Message-----
> From: Nick Duffek [ mailto:nsd@redhat.com ]
> Sent: Sunday, February 25, 2001 12:52 AM
> To: Dautrevaux@microprocess.com
> Cc: gdb@sources.redhat.com; insight@sources.redhat.com
> Subject: RE: Register group proposal
> 
> 
> On 23-Feb-2001, Bernard Dautrevaux wrote:
> 
> >Perhaps for avoiding an unneeded dependency, that would 
> trigger superfluous
> >recompiles of users of "abc.h" that do not need "xyz.h" if "xyz.h" is
> >modified?
> 
> I agree that's a pain.  But prohibiting typedefs only avoids a small
> subset of superfluous recompiles.  For example, changing a 
> single macro in
> gdbarch.h causes a massive rebuild.
> 
> Eventually, GCC probably will support header file compilation, which
> probably will lead to fully-accurate dependency generation.  This will
> eliminate superfluous recompiles.
> 
> In the meantime, the problem diminishes as hardware speedups 
> outpace GCC
> complexity.
> 
> However, humans won't ever get better at writing maintainable code or
> understanding existing code.  Typedefs help us achieve both of those
> goals.

I must say that, although it's a bit shorter, I don't see a real advantage
to define some interface type xxx for

(1) typedef struct { ... } xxx;
    void f(xxx*);

and 

(2) struct xxx;
    void f(struct xxx*);

If you want to get rid of the "struct" in the interface you can go a bit
further:

(3) #ifndef xxx_t
    #define xxx_t struct xxx
    #endif
    void f(xxx_t*);

You can even go even farther and eliminate the '*' from interfaces:

(4) #ifndef xxx_t_defined
    #define xxx_t_defined
    typedef struct xxx* xxx_t;
    #endif
    void f(xxx_t);

Personally, I always use approach (2) and never had any problem, but this
may be biased by the fact that most of my own code is written in C++, so the
typedef is implicit and (2) is roughly equivalent to (1), but with the
advantage that xxx is an opaque type, something IMNSHO greatly compensate
for the need to add the "struct" keyword in C.

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

Re: Register group proposal

[Christopher Faylor]

On Mon, Feb 26, 2001 at 02:10:25PM +0100, Bernard Dautrevaux wrote:
>> -----Original Message-----
>> From: Nick Duffek [ mailto:nsd@redhat.com ]
>> Sent: Sunday, February 25, 2001 12:52 AM
>> To: Dautrevaux@microprocess.com
>> Cc: gdb@sources.redhat.com; insight@sources.redhat.com
>> Subject: RE: Register group proposal
>> 
>> 
>> On 23-Feb-2001, Bernard Dautrevaux wrote:
>> 
>> >Perhaps for avoiding an unneeded dependency, that would 
>> trigger superfluous
>> >recompiles of users of "abc.h" that do not need "xyz.h" if "xyz.h" is
>> >modified?
>> 
>> I agree that's a pain.  But prohibiting typedefs only avoids a small
>> subset of superfluous recompiles.  For example, changing a 
>> single macro in
>> gdbarch.h causes a massive rebuild.
>> 
>> Eventually, GCC probably will support header file compilation, which
>> probably will lead to fully-accurate dependency generation.  This will
>> eliminate superfluous recompiles.
>> 
>> In the meantime, the problem diminishes as hardware speedups 
>> outpace GCC
>> complexity.
>> 
>> However, humans won't ever get better at writing maintainable code or
>> understanding existing code.  Typedefs help us achieve both of those
>> goals.
>
>I must say that, although it's a bit shorter, I don't see a real advantage
>to define some interface type xxx for
>
>(1) typedef struct { ... } xxx;
>    void f(xxx*);
>
>and 
>
>(2) struct xxx;
>    void f(struct xxx*);

That works fine if xxx is a struct.  If, at some point, you have an
amazing idea that allows you to change all xxx's to "unsigned short"
you're stuck with a lot of editing.

cgf

Re: Register group proposal

[Andrew Cagney]

> That works fine if xxx is a struct.  If, at some point, you have an
> amazing idea that allows you to change all xxx's to "unsigned short"
> you're stuck with a lot of editing.

Um, are you being serious here?

	enjoy,
		Andrew

Re: Register group proposal

[Christopher Faylor]

On Mon, Feb 26, 2001 at 01:54:19PM -0500, Andrew Cagney wrote:
>>That works fine if xxx is a struct.  If, at some point, you have an
>>amazing idea that allows you to change all xxx's to "unsigned short"
>>you're stuck with a lot of editing.
>
>Um, are you being serious here?

Do you have some kind of problem with this simple concept?  Been programming
long?

cgf

Re: Register group proposal

[Andrew Cagney]

Christopher Faylor wrote:
> 
> On Mon, Feb 26, 2001 at 01:54:19PM -0500, Andrew Cagney wrote:
> >>That works fine if xxx is a struct.  If, at some point, you have an
> >>amazing idea that allows you to change all xxx's to "unsigned short"
> >>you're stuck with a lot of editing.
> >
> >Um, are you being serious here?
> 
> Do you have some kind of problem with this simple concept?  Been programming
> long?

GDB is made up of several objects.  Some have been identified - a frame,
an architecture, the cli output device (ui-file / ui-out), and even a
proposal for reggroup .... Others are still lurking beneath the surface.

I don't think you are seriously suggesting that one of these
``fundamental'' objects - ex ``struct gdbarch *'' - be replaced by
``unsigned short''.

	enjoy,
		Andrew

Re: Register group proposal

[Christopher Faylor]

On Mon, Feb 26, 2001 at 08:00:09PM -0500, Andrew Cagney wrote:
>Christopher Faylor wrote:
>> 
>> On Mon, Feb 26, 2001 at 01:54:19PM -0500, Andrew Cagney wrote:
>> >>That works fine if xxx is a struct.  If, at some point, you have an
>> >>amazing idea that allows you to change all xxx's to "unsigned short"
>> >>you're stuck with a lot of editing.
>> >
>> >Um, are you being serious here?
>> 
>> Do you have some kind of problem with this simple concept?  Been programming
>> long?
>
>GDB is made up of several objects.  Some have been identified - a
>frame, an architecture, the cli output device (ui-file / ui-out), and
>even a proposal for reggroup ....  Others are still lurking beneath the
>surface.
>
>I don't think you are seriously suggesting that one of these
>``fundamental'' objects - ex ``struct gdbarch *'' - be replaced by
>``unsigned short''.

I believe that someone did suggest using an "fd style" interface where
you are passing around a "handle" or a "cookie" rather than a pointer
to a struct/union/whatever.

However, I was just responding to the general point of typedefs being
useless, and the argument that struct could be used everywhere in place
of a typedef.  I was not advocating a particular implementation, just
noting, as others have, that there were advantages to their use.

I have never heard of another project that bans the use of typedefs
but I guess there aren't many projects like gdb.

cgf

Re: Register group proposal

[Andrew Cagney]

> I have never heard of another project that bans the use of typedefs
> but I guess there aren't many projects like gdb.

Que?

RE: Register group proposal

[Bernard Dautrevaux]

> -----Original Message-----
> From: Nick Duffek [ mailto:nsd@redhat.com ]
> Sent: Thursday, February 22, 2001 7:24 PM
> To: ac131313@cygnus.com
> Cc: gdb@sources.redhat.com; insight@sources.redhat.com
> Subject: Re: Register group proposal
> 
> 
> On 22-Feb-2001, Andrew Cagney wrote:
> 
> >And that illustrates the problem - why should "abc.h" suck in "xyz.h"
> >when clients of "abc.h" may not use any of "xyz"'s methods.
> 
> So that we may use typedefs in the standard and obvious manner.
> 
> What's the problem with "abc.h" sucking in "xyz.h"?  The 
> usual "#ifndef
> abc_h" envelope takes care of multiple-inclusion problems.

Perhaps for avoiding an unneeded dependency, that would trigger superfluous
recompiles of users of "abc.h" that do not need "xyz.h" if "xyz.h" is
modified? note that if your dependencies are kept up to date (something I
hope is true) you also end up with a lot bigger dependency lists, and thus
slower "make" processes, even if everything is already up-to-date ;-(

Another problem may be seen as "name space pollution": If you don't mind
about "xyz.h" why should you be prevented using some identifiers colliding
with the private parts of it?

As a rule of thumb, a header should only #include things it really NEEDS,
and try to avoid these as far as possible.

My 0.02$

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

RE: Register group proposal

[Nick Duffek]

On 23-Feb-2001, Bernard Dautrevaux wrote:

>Perhaps for avoiding an unneeded dependency, that would trigger superfluous
>recompiles of users of "abc.h" that do not need "xyz.h" if "xyz.h" is
>modified?

I agree that's a pain.  But prohibiting typedefs only avoids a small
subset of superfluous recompiles.  For example, changing a single macro in
gdbarch.h causes a massive rebuild.

Eventually, GCC probably will support header file compilation, which
probably will lead to fully-accurate dependency generation.  This will
eliminate superfluous recompiles.

In the meantime, the problem diminishes as hardware speedups outpace GCC
complexity.

However, humans won't ever get better at writing maintainable code or
understanding existing code.  Typedefs help us achieve both of those
goals.

>Another problem may be seen as "name space pollution": If you don't mind
>about "xyz.h" why should you be prevented using some identifiers colliding
>with the private parts of it?

Regardless of whether we nest include files, global namespace clashes are
  (1) a concern that is
  (2) avoidable by using naming conventions minimizing the likelihood of
      clashes.

Nick

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:
> But prohibiting typedefs ....

When implementing an ``object'', I'm asking that it be done in a way
that is consistent with other recent additions to gdb - that is
blah.[hc] defines an opaque ``struct blah *''.  (As a style its
advantages and disadvantages have probably now been beaten to death :-)

While it does implicitly put a restriction on the use of typedefs in
certain header files, it is not a prohibition of typedef.

If someone feels that they have concerns when defining a specific
interface then I would assume that that person will also put those
concerns forward.  In doing this they may well demonstrate a possible
need to implement their interface in a way that is different to the
above.

To give an example, consider LONGEST.  One day that type will need to be
extended beyond 64 bits (long long).  When that happens, it might be
done with something like:
	defs.h:
	  struct longest {
	    something_goes here;
	  };
	  typedef struct longest LONGEST;
Among the rationale would be the observation that LONGEST is a self
contained lightweight.  You could try to implement it as a ``struct
longest *'' but it would make memory management a nightmare while
showing very few advantages.  Being able to perform the mechanical
replacement:
	a = b + c;
  with	a = add (b, c);
would be of much greater benefit.  (See sim/common/sim-fpu.[hc].)

	Andrew

Re: Register group proposal

[Jim Kleck]

A consistent interface is *one* reason to have a particular interface.
However, it is not the only thing to consider, nor have the "style
advantages and disadvantages" been fully explored... at least not
in this forum.

I would note that "struct blah *" is NOT fully opaque. Its very use implies
a control structure of some sort, and it is quite different from the standard
types provided by the language. Thus it is not using the full "extensability"
of the language.

An alternative I have not seen discussed is to have "typedef void * blah"
as the public interface (then the implementation would need to cast
the object to the internal representation before operating on it).

Finally, in the "LONGEST" example, why replace "a = b + c;" with
"a = add(b, c);". My inclination would be to overload the "+" so that
no change to the users of the type are necessary.

JimK


Andrew Cagney wrote:

> Nick Duffek wrote:
> > But prohibiting typedefs ....
>
> When implementing an ``object'', I'm asking that it be done in a way
> that is consistent with other recent additions to gdb - that is
> blah.[hc] defines an opaque ``struct blah *''.  (As a style its
> advantages and disadvantages have probably now been beaten to death :-)
>
> While it does implicitly put a restriction on the use of typedefs in
> certain header files, it is not a prohibition of typedef.
>
> If someone feels that they have concerns when defining a specific
> interface then I would assume that that person will also put those
> concerns forward.  In doing this they may well demonstrate a possible
> need to implement their interface in a way that is different to the
> above.
>
> To give an example, consider LONGEST.  One day that type will need to be
> extended beyond 64 bits (long long).  When that happens, it might be
> done with something like:
>         defs.h:
>           struct longest {
>             something_goes here;
>           };
>           typedef struct longest LONGEST;
> Among the rationale would be the observation that LONGEST is a self
> contained lightweight.  You could try to implement it as a ``struct
> longest *'' but it would make memory management a nightmare while
> showing very few advantages.  Being able to perform the mechanical
> replacement:
>         a = b + c;
>   with  a = add (b, c);
> would be of much greater benefit.  (See sim/common/sim-fpu.[hc].)
>
>         Andrew

Re: Register group proposal

[Per Bothner]

Jim Kleck <jim.kleck@NetergyNet.COM> writes:

> An alternative I have not seen discussed is to have "typedef void * blah"
> as the public interface (then the implementation would need to cast
> the object to the internal representation before operating on it).

Then we lose the ability of the compiler to catch type errors.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Register group proposal

[Jim Kleck]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

Per Bothner wrote:
Jim Kleck <jim.kleck@NetergyNet.COM> writes:
> An alternative I have not seen discussed is to have "typedef void
* blah"
> as the public interface (then the implementation would need to cast
> the object to the internal representation before operating on it).
Then we lose the ability of the compiler to catch type errors.
--
        --Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Good point. I guess that leaves:
   struct blah;
   typedef struct blah *T_BLAH;
which preserves the type errors and simplifies the declaration of
objects of the desired type:
   T_BLAH this_blah;
vs.
   struct blah *this_blah;
JimK
 

Re: Register group proposal

[Andrew Cagney]

Jim Kleck wrote:

> which preserves the type errors and simplifies the declaration of
> objects of the desired type:
> 
>    T_BLAH this_blah;
> 
> vs.
> 
>    struct blah *this_blah;

To go full circle, I guess :-)

The thing about a typedef is that there can really only be one or each
name amonst all of your header files.  The choices are rougly: don't
have the typedef and have each blah.h independant; use a typedef in
blah.h and have everything refering to blah.h suck it in; put the
typedef in defs.h; or have defs.h just suck in blah.h.

All the recent objects have used ``struct blah *'' giving fairly
independant header files.  The older GDB code lived on a diet that
consisted on all of the above.

	enjoy,
		Andrew

Re: Register group proposal

[Michael Elizabeth Chastain]

> Hmm, I think like MichaelC you may have missed the point.

No, actually, the point I missed was a different point.  :)

(Specifically, that a single opaque "typedef struct xyz xyz_t"
works properly, but having several identical lines like that in
one compilation unit isn't legal C).

Michael

Register group proposal

[Nick Duffek]

On an architecture with a large register set, GDBtk's register window can
be difficult to read and slow to update.  Users can customize the window
to hide individual registers, but that's a tedious procedure.

Therefore, users would benefit from being able to switch easily between
register subsets.

The CLI already provides two register subsets:
  1. non-floating-point registers, displayed by "info registers";
  2. all registers, displayed by "info all-registers".

This grouping is not as useful as it could be, for various reasons:

  - Not all architectures have floating-point registers.

  - Many architectures have non-floating-point registers that, like
    floating-point registers, are only interesting to the user in special
    circumstances and that therefore waste limited screen space in most
    circumstances.

  - Some pseudo-registers might not be appropriate in either "info
    registers" or "info all-registers" output.  For example, if an
    architecture lacks a dedictated frame pointer register but its ABI
    stores the frame pointer in general register r31, then "fp" and "r31"
    might be aliases for the same register.  It would not be useful to
    display both fp and r31 in "info all-registers" output.

Whoever ports GDB to a particular architecture is likely to have a good
idea of what register groupings would be useful.

I propose the following gdbarch.sh macros with which architectures can
define register groupings:

  /* Return a null-terminated list of register group names.  */
  char **REGISTER_GROUPS (void)

  /* Return the REGISTER_GROUPS index of the group that "info registers"
     should display.  */
  int REGISTERS_SOME (void)

  /* Return the REGISTER_GROUPS index of the group that "info
     all-registers" should display.  */
  int REGISTERS_ALL (void)

The register cache would define these gdbarch.sh macros:

  /* Return the number of the first register to display in GROUP, which is
     an index in REGISTER_GROUPS.  */
  int REGISTER_INFO_FIRST (int group)

  /* Return the number of the register to display after register REGNUM
     in GROUP, which is an index in REGISTER_GROUPS.  If no registers
     should be displayed after register REGNUM, return -1.  */
  int REGISTER_INFO_NEXT (int group, int regnum)

GDBtk could use REGISTER_GROUPS to generate a menu of register windows.
Users could still customize window contents, but the predefined sets
might make customization unnecessary for most users.

The CLI "info registers" command already accepts a register name as an
optional paramter.  It could be extended to try that parameter as a group
name first and a register name second, so e.g. "info registers float"
would display all floating-point registers.

What do you think?

Nick

Re: Register group proposal

[Fernando Nasser]

This is a long sought after feature.

From the Insight TODO:


--

Register Window capable of handling large number of registers, typed
registers, registers organized in groups that can be shown/hidden and
that provide for better screen organization.

--


The idea is to have a combobox in the register window where the user can
select which group of registers to show (or to show all).



P.S.: On the CLI side, I like the "info registers float" idea.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Register group proposal

[Nick Duffek]

On 21-Feb-2001, Fernando Nasser wrote:

>The idea is to have a combobox in the register window where the user can
>select which group of registers to show (or to show all).

I wonder whether it'd be useful to allow multiple register windows, each
displaying a different group.

Nick

Re: Register group proposal

[Fernando Nasser]

Nick Duffek wrote:
> 
> On 21-Feb-2001, Fernando Nasser wrote:
> 
> >The idea is to have a combobox in the register window where the user can
> >select which group of registers to show (or to show all).
> 
> I wonder whether it'd be useful to allow multiple register windows, each
> displaying a different group.
> 

Yes, that is the idea.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Register group proposal

[Keith Seitz]

On Wed, 21 Feb 2001, Nick Duffek wrote:

> On 21-Feb-2001, Fernando Nasser wrote:
> 
> >The idea is to have a combobox in the register window where the user can
> >select which group of registers to show (or to show all).
> 
> I wonder whether it'd be useful to allow multiple register windows, each
> displaying a different group.

Nick, I think this is all a great idea! I was worried for a while that I 
would have to extend Insight's stupid "target database" even more than we 
already have. It's amazing how much more information a GUI needs compared 
to the command line.

I am always happy to see things get pushed back into gdb proper, 
especially when there is command line access to the same functionality 
(so that means that dejagnu can test the underlying infrastructure).

I hope the people on the other side of the fence realize the utility in 
such an interface.

And, yes, having multiple register windows would be useful. I am going to 
push back to the philosophy that it would be useful to have multiples of 
any window -- some tracking the current execution status of the target, 
some 'frozen'. Heck, if we ever get to multi-arch Insight, we'll need the 
ability to track, say, different CPUs (and possibly register sets) in the 
same session.

Keith

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:
> 
> On an architecture with a large register set, GDBtk's register window can
> be difficult to read and slow to update.  Users can customize the window
> to hide individual registers, but that's a tedious procedure.
> 
> Therefore, users would benefit from being able to switch easily between
> register subsets.
> 
> The CLI already provides two register subsets:
>   1. non-floating-point registers, displayed by "info registers";
>   2. all registers, displayed by "info all-registers".
> 
> This grouping is not as useful as it could be, for various reasons:

Nick,

Refering to the diagram:

> Actually, try this:
> 
>             context
>              /    \  .----.
>             /      \ |    |
>            /      frame---'
>           /       /   \
>    continuation  /     \
>         |       /       \
>         |      /         \
>         |   memcache   regcache
>         |      |           |
> ..........................................
>         |      |           |
>    targ-run  targ-mem  targ-regs

If I understand correctly, the methods you're describing would apply to
a ``frame''.  As the user moves up and down between frames, the
information provided by those methods could change.

Is that correct?

	Andrew

Re: Register group proposal

[Andrew Cagney]

Andrew Cagney wrote:
> 
> Nick Duffek wrote:
> >
> > On an architecture with a large register set, GDBtk's register window can
> > be difficult to read and slow to update.  Users can customize the window
> > to hide individual registers, but that's a tedious procedure.
> >
> > Therefore, users would benefit from being able to switch easily between
> > register subsets.
> >
> > The CLI already provides two register subsets:
> >   1. non-floating-point registers, displayed by "info registers";
> >   2. all registers, displayed by "info all-registers".
> >
> > This grouping is not as useful as it could be, for various reasons:
> 
> Nick,

Hmm, to expand a little:

> > Actually, try this:
> >
> >             context
> >              /    \  .----.
> >             /      \ |    |
> >            /      frame---'
> >           /       /   \
> >    continuation  /     \
> >         |       /       \
> >         |      /         \
> >         |   memcache   regcache
> >         |      |           |
> > ..........................................
> >         |      |           |
> >    targ-run  targ-mem  targ-regs

I think this interface is bound to the ``frame''.  It is the frame, and
not regcache, that determines the current architecture.  With that in
mind, I suspect that the implementation would end up looking like:

	frame.h:

	some date *****gimi_register_groups_for_frame (struct frame_info *);

where you might have:

	frame.c:

	some data *****
	gimi_register_groups_for_frame (struct_frame_info *frame)
	{
	   return gimi_gdbarch_register_groups_for_frame (frame->arch, frame?,
...???);
	}

Given that at present a frame doesn't have an architecture (instead
there is a hardwired default) an intermediate version could just use the
default - ``current_gdbarch''.

The main points are that:

	o	core-gdb doesn't try to access
		gdbarch directly - instead it
		asks the frame what it thinks.

	o	the information isn't in someway
		bound to the raw byte register
		cache.

	Andrew

Re: Register group proposal

[Nick Duffek]

On 21-Feb-2001, Andrew Cagney wrote:

>If I understand correctly, the methods you're describing would apply to
>a ``frame''.  As the user moves up and down between frames, the
>information provided by those methods could change.

>Is that correct?

Yes: if different frames have different register sets, then different
frames would have different register groups.

Nick

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:
> 
> On an architecture with a large register set, GDBtk's register window can
> be difficult to read and slow to update.  Users can customize the window
> to hide individual registers, but that's a tedious procedure.

Much thanks for posting this.  It is at a level that makes discussion
easy.

> Therefore, users would benefit from being able to switch easily between
> register subsets.
[...]
> Whoever ports GDB to a particular architecture is likely to have a good
> idea of what register groupings would be useful.

I definitly agree with the idea.  I've several generic and some specific
thoughts.

--

Per other e-mail.  I think this interface is bound to the ``frame''.  It
is the frame, and not regcache, that determines the current
architecture.  With that in mind, I suspect that the implementation
would end up looking like:

	frame.h:

	some table *****gimi_register_groups_for_frame (struct frame_info *);

where you might have:

	frame.c:

	some table *****
	gimi_register_groups_for_frame (struct_frame_info *frame)
	{
	   return gimi_gdbarch_register_groups_for_frame (frame->arch, frame?,
...???);
	}

Given that at present a frame doesn't have an architecture (instead
there is a hardwired default) an intermediate version could just use the
default - ``current_gdbarch''.

The main thing is that core-gdb wouldn't try to access gdbarch directly
when obtaining this information.

--





> I propose the following gdbarch.sh macros with which architectures can
> define register groupings:
> 
>   /* Return a null-terminated list of register group names.  */
>   char **REGISTER_GROUPS (void)
> 
>   /* Return the REGISTER_GROUPS index of the group that "info registers"
>      should display.  */
>   int REGISTERS_SOME (void)
> 
>   /* Return the REGISTER_GROUPS index of the group that "info
>      all-registers" should display.  */
>   int REGISTERS_ALL (void)
> 
> The register cache would define these gdbarch.sh macros:
> 
>   /* Return the number of the first register to display in GROUP, which is
>      an index in REGISTER_GROUPS.  */
>   int REGISTER_INFO_FIRST (int group)
> 
>   /* Return the number of the register to display after register REGNUM
>      in GROUP, which is an index in REGISTER_GROUPS.  If no registers
>      should be displayed after register REGNUM, return -1.  */
>   int REGISTER_INFO_NEXT (int group, int regnum)
> 
> GDBtk could use REGISTER_GROUPS to generate a menu of register windows.
> Users could still customize window contents, but the predefined sets
> might make customization unnecessary for most users.
> 
> The CLI "info registers" command already accepts a register name as an
> optional paramter.  It could be extended to try that parameter as a group
> name first and a register name second, so e.g. "info registers float"
> would display all floating-point registers.
> 
> What do you think?
> 
> Nick

Re: Register group proposal

[Andrew Cagney]

Oops.  If you think you're seeing double it is because you are :-(

The below was a draft that I didn't mean to send.  I broke this message
into two separate posts (they addressed separate issues) only to then
sent this one instead of the other two.

Could I suggest responding to the other two threads instead.

	sorry,
		Andrew

Andrew Cagney wrote:
> 
> Nick Duffek wrote:
> >
> > On an architecture with a large register set, GDBtk's register window can
> > be difficult to read and slow to update.  Users can customize the window
> > to hide individual registers, but that's a tedious procedure.
> 
> Much thanks for posting this.  It is at a level that makes discussion
> easy.
> 
> > Therefore, users would benefit from being able to switch easily between
> > register subsets.
> [...]
> > Whoever ports GDB to a particular architecture is likely to have a good
> > idea of what register groupings would be useful.
> 
> I definitly agree with the idea.  I've several generic and some specific
> thoughts.
> 
> --
> 
> Per other e-mail.  I think this interface is bound to the ``frame''.  It
> is the frame, and not regcache, that determines the current
> architecture.  With that in mind, I suspect that the implementation
> would end up looking like:

.
.
.
.

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:

Several thoughts on the interface.  Again mostly generic.

--

Rather than a simple integer, should reggroup be made an object vis
``struct reggroup *''?

I think one of the maintenance problems with GDB's current internals is
that it uses integers for many and varied things.  It is just too easy
to pass an integer intended for one purpose to a function where the
meaning is different.  It is also too easy to extract implied
information from it.

As an example, GDB kicks around a REGNUM when, it really means two
separate things - a register that is part of a frame; and an entry in
the raw register cache.  If REGNUM, was strongly typed the separation of
the two uses would be forced.  While that won't happen to REGNUM for a
very long time, I would like newer types to be made strongly typed so
that the same mistakes are less likely to happen again.

This may affect things like ``REGISTER_GROUPS()''.

Even if it isn't made an object could I suggest the convention of a
...._REGGROUP() be adopted to all methods that return a register group.

--

The interface defines an iterator:

>   /* Return the number of the first register to display in GROUP, which is
>      an index in REGISTER_GROUPS.  */
>   int REGISTER_INFO_FIRST (int group)
> 
>   /* Return the number of the register to display after register REGNUM
>      in GROUP, which is an index in REGISTER_GROUPS.  If no registers
>      should be displayed after register REGNUM, return -1.  */
>   int REGISTER_INFO_NEXT (int group, int regnum)

I guess this is called as something like (I'll take the liberty of using
slightly different names):

	for (regnum = REGGROUP_FIRST_REGNUM (reggroup);
	     regnum >= 0;
	     retnum = REGGROUP_NEXT_REGNUM (reggroup, regnum))
	  {
	     apply regnum;
	  }

As an iterator it is the natural choice.  Perhaphs it should be adopted
as the convention to use when both a GDB object needs an iterator and
the members of that list are constant (reggrop won't change but the
breakpoint list could change).





--

>   /* Return a null-terminated list of register group
> names.  */
>   char **REGISTER_GROUPS (void)

Would such a table be released using freeargv() like many of the BFD
interfaces?

>   /* Return the REGISTER_GROUPS index of the group that
> "info registers"
>      should display.  */
>   int REGISTERS_SOME (void)

Perhaphs

	...._DEFAULT_REGROUP()

>   /* Return the REGISTER_GROUPS index of the group that
> "info
>      all-registers" should display.  */
>   int REGISTERS_ALL (void)

Hmm, is there a case when ``info all-registers'' doesn't display all the
registers?

	Andrew

Re: Register group proposal

[Eli Zaretskii]

On Wed, 21 Feb 2001, Andrew Cagney wrote:

> I guess this is called as something like (I'll take the liberty of using
> slightly different names):
> 
> 	for (regnum = REGGROUP_FIRST_REGNUM (reggroup);
> 	     regnum >= 0;
> 	     retnum = REGGROUP_NEXT_REGNUM (reggroup, regnum))
> 	  {
> 	     apply regnum;
> 	  }

If we are to use an iterator, shouldn't the test in this loop be
abstracted as well, like this, for instance?

 	for (regnum = REGGROUP_FIRST_REGNUM (reggroup);
 	     REGGROUP_NOT_LAST_REGNUM (reggroup);
 	     regnum = REGGROUP_NEXT_REGNUM (reggroup, regnum))
 	  {
 	     apply regnum;
 	  }

Re: Register group proposal

[Nick Duffek]

On 22-Feb-2001, Eli Zaretskii wrote:

>If we are to use an iterator, shouldn't the test in this loop be
>abstracted as well, like this, for instance?

Not necessarily: something like REGGROUP_FIRST_REGNUM and
REGGROUP_NEXT_REGNUM are required for implementing multiple groups, but
REGGROUP_NOT_LAST_REGNUM isn't.

REGGROUP_NOT_LAST_REGNUM is consistent with the notion of changing integer
register numbers into opaque identifiers (aka handles or cookies).

But declaring that -1 is a reserved register identifier doesn't tie our
hands much interface-wise.  It works pretty well for various UNIX file and
memory interfaces.

Maybe we need to establish some GDB coding policies about handles defined
and passed around by abstract interfaces: should they be ints, struct
pointers, typedefs, etc., and should there be a known-invalid value such
as -1 or NULL?

At any rate, for now I'd like to avoid the question for register numbers
and stick with existing convention, namely that register handles are ints
and -1 is invalid.

Nick

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:
> 
> On 22-Feb-2001, Eli Zaretskii wrote:
> 
> >If we are to use an iterator, shouldn't the test in this loop be
> >abstracted as well, like this, for instance?
> 
> Not necessarily: something like REGGROUP_FIRST_REGNUM and
> REGGROUP_NEXT_REGNUM are required for implementing multiple groups, but
> REGGROUP_NOT_LAST_REGNUM isn't.
> 
> REGGROUP_NOT_LAST_REGNUM is consistent with the notion of changing integer
> register numbers into opaque identifiers (aka handles or cookies).
> 
> But declaring that -1 is a reserved register identifier doesn't tie our
> hands much interface-wise.  It works pretty well for various UNIX file and
> memory interfaces.
> 
> Maybe we need to establish some GDB coding policies about handles defined
> and passed around by abstract interfaces: should they be ints, struct
> pointers, typedefs, etc., and should there be a known-invalid value such
> as -1 or NULL?

To add to this, there are two classes of iterators:

	o	like the above where things don't
		change under your feet.

	o	nasty ones where where you're
		doing a transformation.  Vis:

		for everything in the old group
		   if blah
		      it stays in the group
		   else
		      it is removed from the group

		breakpoints have this problem but
		per my other comment that is a very
		separate problem to what is happening
		here.

For the simple first case, I think it is reasonable for a programmer to
expect the corresponding code to look like either:

	int group;
	for (group = ...; group >= 0; group = ...) { ... };
or
	struct reggroup *group;
	for (group = ...; group != NULL; group = ...) { ... }'

since in each case they are the natural sentinal.

In the integer case, the only thing I would encourage is that the test
be the looser but more robust ``... >= 0'' rather then the very exact
``... == -1''.

	Andrew

Re: Register group proposal

[Keith Seitz]

On Thu, 22 Feb 2001, Andrew Cagney wrote:

> To add to this, there are two classes of iterators:
> 
> 	o	nasty ones where where you're
> 		doing a transformation.  Vis:
> 
> 		for everything in the old group
> 		   if blah
> 		      it stays in the group
> 		   else
> 		      it is removed from the group
> 
> 		breakpoints have this problem but
> 		per my other comment that is a very
> 		separate problem to what is happening
> 		here.

Are you tempting me with user-defined groups?

:-)
Keith

Re: Register group proposal

[Andrew Cagney]

Keith Seitz wrote:
> 
> On Thu, 22 Feb 2001, Andrew Cagney wrote:
> 
> > To add to this, there are two classes of iterators:
> >
> >       o       nasty ones where where you're
> >               doing a transformation.  Vis:
> >
> >               for everything in the old group
> >                  if blah
> >                     it stays in the group
> >                  else
> >                     it is removed from the group
> >
> >               breakpoints have this problem but
> >               per my other comment that is a very
> >               separate problem to what is happening
> >               here.
> 
> Are you tempting me with user-defined groups?

Why not? A reggroup is just a list of regnums.  No reason for that list
to be static.
Hmm, perhaphs in the second iteration.

	Andrew

Re: Register group proposal

[Nick Duffek]

On 21-Feb-2001, Andrew Cagney wrote:

>Rather than a simple integer, should reggroup be made an object vis
>``struct reggroup *''?

Perhaps so.  It's not a struct at the moment, though, and even if it were,
declaring it as such implies that clients of the interface have access to
fields of the struct, which either (a) is untrue or (b) leaks internal
information across the interface.

I'd rather typedef it to something that'll cause compile-time errors if
it's used as anything other than an opaque handle.  That change probably
would require more discussion, so for now I'd prefer to use an int.

Going one step further, REGISTER_GROUPS should be defined as a pair of
FIRST/NEXT iterator macros plus a NAME macro:

  /* Return the first register group to display.  */
  int REGGROUP_FIRST (void)

  /* Return the register group to display after GRP.  -1 means there
     aren't any more groups to display.  */
  int REGGROUP_NEXT (int grp)

  /* Return the name of register group GRP.  */
  char *REGGROUP_NAME (int grp)

>Even if it isn't made an object could I suggest the convention of a
>...._REGGROUP() be adopted to all methods that return a register group.

Yes, that's helpful for supporting Stephane's idea of using register
groups for purposes other than display, e.g. fetching and storing.

>>   /* Return a null-terminated list of register group
>> names.  */
>>   char **REGISTER_GROUPS (void)

>Would such a table be released using freeargv() like many of the BFD
>interfaces?

No, it never would be released, because it would be part of a gdbarch.
But this question is bypassed by the REGGROUP_FIRST change.

>>   /* Return the REGISTER_GROUPS index of the group that
>> "info registers"
>>      should display.  */
>>   int REGISTERS_SOME (void)

>Perhaphs

>	...._DEFAULT_REGROUP()

Agreed.

>>   /* Return the REGISTER_GROUPS index of the group that
>> "info
>>      all-registers" should display.  */
>>   int REGISTERS_ALL (void)

>Hmm, is there a case when ``info all-registers'' doesn't display all the
>registers?

I proposed such a case in my original message:

  - Some pseudo-registers might not be appropriate in either "info
    registers" or "info all-registers" output.  For example, if an
    architecture lacks a dedictated frame pointer register but its ABI
    stores the frame pointer in general register r31, then "fp" and "r31"
    might be aliases for the same register.  It would not be useful to
    display both fp and r31 in "info all-registers" output.

Do you disagree with that case?  Even if you do, though, I don't think we
should impose restrictions on how architectures define register groups.

Nick

Re: Register group proposal

[Fernando Nasser]

Nick Duffek wrote:
> 
> >Hmm, is there a case when ``info all-registers'' doesn't display all the
> >registers?
> 

I don't think control register or things like PentiumIII  MSR  (Model
Specific Registers) should be printed even in info all-registers.

I know the name becomes inappropriate, but what the user expect is "all
user registers", things that are part of the context like the GP and FP
registers plus PC, SP, FP, PSW...

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Register group proposal

[Andrew Cagney]

Fernando Nasser wrote:
> 
> Nick Duffek wrote:
> >
> > >Hmm, is there a case when ``info all-registers'' doesn't display all the
> > >registers?
> >
> 
> I don't think control register or things like PentiumIII  MSR  (Model
> Specific Registers) should be printed even in info all-registers.
> 
> I know the name becomes inappropriate, but what the user expect is "all
> user registers", things that are part of the context like the GP and FP
> registers plus PC, SP, FP, PSW...

Ah, thanks.  This provides a defintion that is independant of the way
registers are currently implemented.

	Andrew

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:
> 
> On 21-Feb-2001, Andrew Cagney wrote:
> 
> >Rather than a simple integer, should reggroup be made an object vis
> >``struct reggroup *''?
> 
> Perhaps so.  It's not a struct at the moment, though, and even if it were,
> declaring it as such implies that clients of the interface have access to
> fields of the struct, which either (a) is untrue or (b) leaks internal
> information across the interface.
> 
> I'd rather typedef it to something that'll cause compile-time errors if
> it's used as anything other than an opaque handle.  That change probably
> would require more discussion, so for now I'd prefer to use an int.

I'm sorry but you've lost me here.

Have a look at ui-out.h, ui-file.h, gdbarch.h, ...  They have all used
``struct foo *'' to implement an opaque type.  In all cases it isn't
possible to get to the inner workings.

Regarding typedefs.  Per my e-mail
http://sources.redhat.com/ml/gdb-patches/2001-02/msg00325.html it
encouraging a tangled web of includes.

enjoy,
	Andrew

Re: Register group proposal

[Nick Duffek]

On 22-Feb-2001, Andrew Cagney wrote:

>Have a look at ui-out.h, ui-file.h, gdbarch.h, ...  They have all used
>``struct foo *'' to implement an opaque type.  In all cases it isn't
>possible to get to the inner workings.

I've noticed, and I've spent time scratching my head over why structs are
used in various places.

>Regarding typedefs.  Per my e-mail
> http://sources.redhat.com/ml/gdb-patches/2001-02/msg00325.html it
>encouraging a tangled web of includes.

The example you quoted in that email:

   Try declaring something like:

       xyz.h:
           struct xyz;
           exter void xyz_foo (struct xyz *self, ...);

       abc.h:
           struct xyz;
           struct abc;
           extern abc_on_xyz (struct abc *self, struct xyz *on);

   using typedefs.  It ends up creating include spaghetti :-(

is very easy to declare using typedefs.  Here's abc.h:

   #include "xyz.h"

   typedef struct {
     int i;
   } Abc;

   extern int abc_on_xyz (Abc *self, Xyz *on);

Here's xyz.h:

   typedef struct {
     int j;
   } Xyz;

   extern void xyz_foo (Xyz *self);

Do we have an official policy prohibiting typedefs in include files?

Nick

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:

> I've noticed, and I've spent time scratching my head over why structs are
> used in various places.

A struct is a poor persons opaque object.

> >Regarding typedefs.  Per my e-mail
> > http://sources.redhat.com/ml/gdb-patches/2001-02/msg00325.html it
> >encouraging a tangled web of includes.
> 
> The example you quoted in that email:
> 
>    Try declaring something like:
> 
>        xyz.h:
>            struct xyz;
>            exter void xyz_foo (struct xyz *self, ...);
> 
>        abc.h:
>            struct xyz;
>            struct abc;
>            extern abc_on_xyz (struct abc *self, struct xyz *on);
> 
>    using typedefs.  It ends up creating include spaghetti :-(
> 
> is very easy to declare using typedefs.  Here's abc.h:

Hmm, I think like MichaelC you may have missed the point.

> is very easy to declare using typedefs.  Here's abc.h:
> 
>    #include "xyz.h"
> 
>    typedef struct {
>      int i;
>    } Abc;
> 
>    extern int abc_on_xyz (Abc *self, Xyz *on);

And that illustrates the problem - why should "abc.h" suck in "xyz.h"
when clients of "abc.h" may not use any of "xyz"'s methods.  If a file
needs to use the method ``xyz_foo()'' then that file should explicitly
include "xyz.h".

It is actually a shame that libremote isn't yet available (yes it is
being worked on ...) Its architecture has everything implemented as
opaque objects.  The header files that define the exported interface are
all fully independant of each other - you don't need to include "abc.h"
to use "xyz.h" and conversely including "abc.h" doesn't quietly suck in
"xyz.h" when its methods are not being used.

> Do we have an official policy prohibiting typedefs in include files?

Using typedefs for things like function declarations? No.

The use of ``typedef struct'' in new interfaces, however, is strongly
discouraged.  You'll notice that all the recently added interfaces have
followed the convention:

	<OBJECT>.h
		struct <OBJECT>;
		<OBJECT>_method (struct <OBJECT> *);

enjoy,
	Andrew

Re: Register group proposal

[Nick Duffek]

On 22-Feb-2001, Andrew Cagney wrote:

>And that illustrates the problem - why should "abc.h" suck in "xyz.h"
>when clients of "abc.h" may not use any of "xyz"'s methods.

So that we may use typedefs in the standard and obvious manner.

What's the problem with "abc.h" sucking in "xyz.h"?  The usual "#ifndef
abc_h" envelope takes care of multiple-inclusion problems.

>The use of ``typedef struct'' in new interfaces, however, is strongly
>discouraged.

Again, is this official policy?  I don't see any references to typedefs in
gdbint.texinfo.

I think there should be explicit agreement by the GDB community before we
adopt such an unusual standard.  Maybe there has been, though, and I've
missed it.

Nick

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:

> I think there should be explicit agreement by the GDB community before we
> adopt such an unusual standard.  Maybe there has been, though, and I've
> missed it.

This convention was agreed to some two years ago when gdbarch and ui-out
were started.  True it wasn't added to the gdbint.texinfo file (back
then nothing was being added to that file :-( ) and some of the
discussion may have occured privatly.  However, since then, I've never
been presented with a compelling argument to to drop this convention and
start down a new random path.

As for the idea, It is lifted from old UNIX header files.

	enjoy,
		Andrew

Re: Register group proposal

[Eli Zaretskii]

> Date: Thu, 22 Feb 2001 13:23:17 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> This convention was agreed to some two years ago when gdbarch and ui-out
> were started.  True it wasn't added to the gdbint.texinfo file (back
> then nothing was being added to that file :-(

If you point me to the relevant discussion in the archives, I can try
to write it up.  Assuming that you don't kill this convention right
here and now, that is ;-)

Re: Register group proposal

[Kevin Buettner]

On Feb 22, 12:10pm, Andrew Cagney wrote:

> > I've noticed, and I've spent time scratching my head over why structs are
> > used in various places.
> 
> A struct is a poor persons opaque object.

But there are other ways to implement opaque objects and using typedef
gives you the freedom to later change your mind about the
implementation details without (also) having to change all of your
declarations.

E.g, regarding the pid/tid/lwp problem, the patch on the table uses
struct ptid * as the opaque object.  As we've discussed in the past,
this has the problem of leaving dangling references in various places
if you attempt to wipe out the current set of ptids.

This problem may be solved via several different means.  The object
in question could be implemented via a struct instead of a pointer
to a struct.  Unfortunately, opaqueness is lost when you use this
approach.  (But this does have the advantage of simplicity.)

Another approach to the problem (which does maintain opacity) is to
represent the ptid as an int which which is an index or key into some
other set of data structures that are maintained behind the scenes. 
This representation avoids the dangling reference problem because the
accessors may validate the ptid (which, remember is a key) and do
something appropriate (e.g, generate an internal error or simply
return a canonical value) when the key is no longer valid.

Anyway, the advantage of using typedef is that we can change the
implementation at will.   For example, we could start off with

    struct ptid;
    typedef struct ptid *ptid;

And later on we could change our minds and do the following:

    typedef int ptid;		/* ptid is an opaque handle which represents
    				   the various identifiers which may be used
				   to represent an execution context. */

I agree that the use of typedef does cause you to have to be more careful
with your includes, but I think we're giving up a very powerful facility
by banning typedef.

Re: Register group proposal

[Andrew Cagney]

Kevin Buettner wrote:

> E.g, regarding the pid/tid/lwp problem, the patch on the table uses
> struct ptid * as the opaque object.  As we've discussed in the past,
> this has the problem of leaving dangling references in various places
> if you attempt to wipe out the current set of ptids.

In the case of the pid/tid/lwp problem, it is not introducing a new
interface. Rather it is massaging existing code into slightly better
shape (but still not perfect).  It is fairly clear that that code will
continue to evolve so some compromise is necessary.  Somewhere in the
future, a true object ma finally appear and be adopted.

For new code providing new interfaces and functionality, however, I take
a different view. I don't see a compelling reason for it to not be
implemented in a style that is consistent with all the other recently
introduced code.  It may not be to personal taste but at least it is
consistent.

In the case of regcache, you'll notice that while I've strongly
encouraged a true regcache object I've not gone as far as dictating it -
I can't .  Nick's pushed back so I suspect it will remain an integer.
 
If however, someone were to take Nick's reggroup idea and implement
Keith's proposal (allow reggroups membership to be changed at runtime),
then I suspect the implementation would need to be moved out of the
architecture vector and made an object in its own right.  At that point
- I would be expecting an implementation that was consistent with ui-out
et.al.

enjoy,
	Andrew

Re: Register group proposal

[Andrew Cagney]

Nick Duffek wrote:

> >Even if it isn't made an object could I suggest the convention of a
> >...._REGGROUP() be adopted to all methods that return a register group.
> 
> Yes, that's helpful for supporting Stephane's idea of using register
> groups for purposes other than display, e.g. fetching and storing.

Just FYI,

Since REGGROUP is bound to a frame and _not_ the raw register cache, it
wouldn't be directly applicable to what Stephane was suggesting.

For an existing example of this unfortunate confusion of layers (and how
it goes wrong) have a look at RAW_REGISTER_BYTES() and how code much of
the code manipulating a frame's cooked/pseudo registers (incorrectly)
uses it.

enjoy,
	Andrew