Re: Remote protocol extension for register ranges

[Fernando Nasser <fnasser@redhat.com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
> Fernando> Presently, the remote protocol can only read all registers
> Fernando> of a target.  This is OK for the context registers (the ones
> Fernando> that are saved by the OD on a context switch) but this is a
> Fernando> serious limitation for machines that have lots of additional
> Fernando> registers.  It is just not feasible to read them all at
> Fernando> every "g" packet.
> 
> If a target has so many registers that you don't want to read them all
> with the "g" command packet, I believe you are going to need something
> similar for the "G" command packet.  Otherwise, any read/modify/write
> operations GDB does will end up reading and writing the entire set.
> 
I agree.  But as you say below, the G packet is a little more complex
and 
we have the P packet already.  I was planning on using P for writes.



> Fernando> I would like to add parameters to the "g" packet.  Something
> Fernando> similar has been proposed before -- the only difference is
> Fernando> that I would like the parameters to be a register number or
> Fernando> a register number range range.
> 
> You could probably get away with adding parameters to the "g" command
> packet --- as far as I can tell none of the sample stubs completely
> parse the command.  But if GDB sent "g" command packet containing a
> register range to such stubs, it would get the entire register set.
> You would have to write a some sort of run time test to determine
> whether it handled register ranges.
> 
Yes, the run time test (as it is done for P packets) is the idea.


> Adding parameters to the "G" command packet is more troublesome ---
> the register values immediately follow the command character.
> 
I was thinking of using 'P'...


> For these reasons, I recommend implementing a new set of commands
> which would deprecate G/g/P/p.
> 
> Perhaps something like:
> 
>    Get Registers:
>         y<start>,<end>
> 
>    Set Registers:
>         Y<start>,<end>,<register-contents>
> 

This may be a nice option, and I would not discard it for the future 
(although I am not sure how I would use it from gdb without mixing some
different levels of information).

I am just planning on making a very small change to gdb and one of the 
stubs so the registers can be shown.  I don't think I will be given much
time to do that so I have to keep it very simple.  That is why I would
still
rather do the 'g' extension (for now) to be able to work with register
numbers
(while an eventual "yY" would work with byte offsets).

Note that this does not precludes the implementation of "yY" later, as
they
have different parameter types (regno's and offsets).  And we extend the
existing
command with the current type of arguments while the new ones, when
implemented,
will have a different type.

> But while we are adding commands, we might want to consider whether
> there are any other arguments we should add.
> 
> One that comes to mind is a thread-id.  Currently, when we want to get
> the registers from several threads on the target, GDB has to issue a
> set thread command before each store/fetch register command.  If the
> thread-id was part of the request, it could significantly improve
> remote protocol performance, especially on low-bandwidth and/or high
> latency connections.
> 
This looks like a time saving operation.  But other people that are
doing
threads work will know better than me.

We can eventually add "t=NNNN,".  Its acceptance can be tested at run
time like the other optimizations/extensions.



-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Problems with "make install"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003191226.HAA08370@indy.delorie.com>
X-SW-Source: 2000-q1/msg00738.html
Content-length: 1424

I'm testing the "make install" targets, and I see several problems
which look like bugs.

1) gdb/Makefile doesn't seem to run mkinstalldirs to create some of
the directories, such as ${prefix}/bin and ${prefix}/man.  Similarly,
gdb/doc/Makefile doesn't create ${prefix}/info and ${prefix}/html.
Why is that?

2) Why doesn't "make install" install the Info docs?  For that matter,
why doesn't "make" doesn't "make info"?  One needs to say "make info"
and "make install-info" to get them, which is different from all the
other GNU project I've seen.

3) The top-level Makefile.in says this:

  INSTALL = $(SHELL) $$s/install-sh -c

This unconditionally forces Make to use the install-sh script for
installation, including in all the subdirectories.

Why is this necessary?  Is it possible to replace this with the usual
Autoconf magic that finds the install program at configure time?  (All
the subdirectories already do that, but the results of those tests are
overridden by the above.)

My problem with this is that install-sh is truncated to "install-" on
8+3 filesystems, and Make then doesn't think it's necessary to run the
commands for targets like install-recursive because it thinks that
install-recursive is a file which already exists.  So the DJGPP
configuration script renames install-sh to a different name, which
then fails because of the above.

Using the normal install program would solve all that nuisance.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BCCA84.74A4143E@cygnus.com>
References: <200002280657.BAA27090@indy.delorie.com>
X-SW-Source: 2000-q1/msg00464.html
Content-length: 814

Eli Zaretskii wrote:
> 
> defs_h in gdb/Makefile includes config.status.  This makes all of the
> GDB sources depend on it.  The result is that each time I reconfigure
> the package, everything gets recompiled, which is quite annoying when
> working on some minor configury buglets.

I guess you're refering to things like Makefile problems.

> Why does GDB need to be dependent on config.status, in addition to
> config.h?

I don't know and yes I agree with you.  I think it is just history.

Grubbing through really old versions of gdb I've found that defs_h was
added on:
	date: 1993/06/23 22:59:13;  author: rich
and it included config.status from day one.  The addition of config.h is
far more recent:
	date: 1996/03/17 00:35:57;  author: fnf

Assuming no one objects, I'll delete it in the morning.

	Andrew
From law@cygnus.com Sat Apr 01 00:00:00 2000
From: Jeffrey A Law <law@cygnus.com>
To: guo@cup.hp.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: hppa 10.20 test result comparison 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20487.953919445@upchuck>
References: <200003232040.MAA14957@cygnus.com>
X-SW-Source: 2000-q1/msg00798.html
Content-length: 633

  In message <200003232040.MAA14957@cygnus.com>you write:
  > This is a comparison of 2/4's gdb and 3/21's.  The sourceware version of
  > 3/21 has disabled elf32-hppa support in bfd, so there's no hpux 11.00
  > comparison for the sourceware version.
elf32-hppa is unsupported and nobody should be using it.  It is unlikely
elf32-hppa will ever be supported again.

For hpux11.00 in 32bit mode you should still be using SOM, so I don't see
why you can't do an hpux11.00 comparison for the sourceware version.

Support for hpux11.00 64bit mode will be contributed once we get final
acceptance on the PA64 toolchain from HP.

jeff