Remote protocol extension for register ranges

Remote protocol extension for register ranges

[Fernando Nasser]

Presently, the remote protocol can only read all registers of a target. 
This is OK for the context registers (the ones that are saved by the OD
on a context switch) but this is a serious limitation for machines that
have lots of additional registers.  It is just not feasible to read them
all at every "g" packet.

I would like to add parameters to the "g" packet.  Something similar has
been proposed before -- the only difference is that I would like the
parameters to be a register number or a register number range range.  

For instance: 

g82      Reads register 82
g31-40   Reads registers 31-40

Gdb would test for the acceptance of these types of packets by the stub
and fall back to the less efficient form if not (like it does for "P"
packets).

I really need this feature as do other people that are dealing with one
of the numerous microprocessors that have too many extra registers.  And
it is becoming quite urgent now.

What is the current thinking about this?  Are there other proposals I am
not aware of?  What are the maintainers position?

-- 
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 jtc@redback.com Wed Mar 22 08:26:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb@sourceware.cygnus.com, Andrew Cagney <cagney@cygnus.com>, taruna@redhat.com, Eric Bachalo <ebachalo@cygnus.com>
Subject: Re: Remote protocol extension for register ranges
Date: Wed, 22 Mar 2000 08:26:00 -0000
Message-id: <5m66ufj7ii.fsf@jtc.redbacknetworks.com>
References: <38D8CFA4.C3535C93@redhat.com>
X-SW-Source: 2000-03/msg00306.html
Content-length: 4736

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

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.

Adding parameters to the "G" command packet is more troublesome ---
the register values immediately follow the command character.

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>

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.

For amusement purposes only, I've enclosed the store and fetch
sections from the specification I've been writing for a replacement
remote protocol.  Other than the register ranges being specified by
offset and length, it's pretty much the same as the above.

        --jtc


4.1 REGISTER FETCH

input:
	context_t	id;
	int		offset;		offset within register data
	int		length;		length of transfer

output:
	int		status;
	char		data[];

This command may yeild unpredicable results if context <id> has not
been suspended.

issues:
	This assumes a single flat address space for all registers.
	It might be convienent to have separate (but potentially
	overlapping) register files for integer registers, floating
	point registers, system registers, miscellaneous registers,
	etc.  

        For example, one register file could contain the PC, FP, SP,
        and whatever other registers are needed on a particular
	architecture for GDB after a signal/exception/breakpoint
	event.  This would solve the problem of what to return in 
	those events.


4.2 REGISTER STORE

input:
	context_t	id;
	int		offset;		offset within register data
	int		length;		length of transfer
	char		data[];

output:
	int		status;

This command may cause unpredictable behavior if context <id> has not
been suspended.

issues:
	see also register fetch.


4.3 MEMORY FETCH

input:
	addr_t		address;	address of transfer
	int		length;		length of transfer
	mode_t		mode;

output:
	int		status;
	char		data[length];

description:
	Returns the contents of the memory region at <address> through
	<address> + <length>.

This command may yeild unpredictable results if all contexts which
access this memory region have not been suspended (unless some mutual
exclusion mechanism is employed).

issues:
	should this command take a "address space" argument?  This
	might be useful for I/O space and bus spaces.  If so, should
	registers simply be considered a "space".

issues:
	should this command take a context id argument as well?  This
	might be desirable if different contexts can have different
	memory mappings.


4.4 MEMORY STORE

input:
	addr_t		address;	address of transfer
	int		length;		length of transfer
	mode_t		mode;
	char		data[length];

output:
	int		status;

description:
	Writes data[] at <address> through <address> + <length>

This command may cause unpredictable results if all contexts which
access this memory have not been suspended (unless some mutual
exclusion mechanisms is employed).

issues:
	see also memory fetch.


-- 
J.T. Conklin
RedBack Networks
From eliz@delorie.com Wed Mar 22 10:10:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Jim Blandy <jimb@zwingli.cygnus.com>
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Wed, 22 Mar 2000 10:10:00 -0000
Message-id: <200003221806.NAA14225@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <npya7c6zn7.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00307.html
Content-length: 724

> Eli's test of the value's type is incorrect if the watch expression
> contains a structure comparison, like (foo == bar) || (something
> else), where foo and bar are structures.  In that case, there will be
> a value of type "struct", not at the end of the value list, but which
> should be watched in its entirety.

Errr... do you have an actual example program where this happens?

I seem to be unable to reproduce the problem, at least in a C program:
whenever I say "watch foo == bar" (where foo and bar are structs), GDB
curses thusly:

	Structure has no component named operator==.

Am I missing something?

In case it matters, I tested this with a DJGPP-compiled program; DJGPP
by default uses COFF debugging info.
From fnasser@redhat.com Wed Mar 22 11:41:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com, Andrew Cagney <cagney@cygnus.com>, taruna@redhat.com, Eric Bachalo <ebachalo@cygnus.com>
Subject: Re: Remote protocol extension for register ranges
Date: Wed, 22 Mar 2000 11:41:00 -0000
Message-id: <38D921AC.A133F89D@redhat.com>
References: <38D8CFA4.C3535C93@redhat.com> <5m66ufj7ii.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-03/msg00308.html
Content-length: 3811

"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 msnyder@cygnus.com Wed Mar 22 12:41:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: Jim Blandy <jimb@cygnus.com>, hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Wed, 22 Mar 2000 12:41:00 -0000
Message-id: <38D92F29.A3D@cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <npya7c6zn7.fsf@zwingli.cygnus.com> <200003221806.NAA14225@indy.delorie.com>
X-SW-Source: 2000-03/msg00309.html
Content-length: 759

Eli Zaretskii wrote:
> 
> > Eli's test of the value's type is incorrect if the watch expression
> > contains a structure comparison, like (foo == bar) || (something
> > else), where foo and bar are structures.  In that case, there will be
> > a value of type "struct", not at the end of the value list, but which
> > should be watched in its entirety.
> 
> Errr... do you have an actual example program where this happens?
> 
> I seem to be unable to reproduce the problem, at least in a C program:
> whenever I say "watch foo == bar" (where foo and bar are structs), GDB
> curses thusly:
> 
>         Structure has no component named operator==.

Argh... gdb does not seem to know that struct compare
is permitted.  I'll publish a patch.

				Michael Snyder
From jtc@redback.com Wed Mar 22 15:54:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb@sourceware.cygnus.com, Andrew Cagney <cagney@cygnus.com>, taruna@redhat.com, Eric Bachalo <ebachalo@cygnus.com>
Subject: Re: Remote protocol extension for register ranges
Date: Wed, 22 Mar 2000 15:54:00 -0000
Message-id: <5mwvmuef3j.fsf@jtc.redbacknetworks.com>
References: <38D8CFA4.C3535C93@redhat.com> <5m66ufj7ii.fsf@jtc.redbacknetworks.com> <38D921AC.A133F89D@redhat.com>
X-SW-Source: 2000-03/msg00310.html
Content-length: 3384

>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
>> 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.

Fernando> I agree.  But as you say below, the G packet is a little
Fernando> more complex and we have the P packet already.  I was
Fernando> planning on using P for writes.

How are you planning on changing remote.c to issue your new fetch
multiple registers command?  The target interface for fetching and
storing registers only supports fetch/storing one or all registers?
There's a deferred store mechanism in the sparc port, but I can not
see anything that fetches a subset of registers.

I'm concerned that if you have a fetch multiple registers command
without a corresponding store multiple registers command, you might
see situations where after reading and modifying a set of registers,
GDB may have to issue many, many P commands.  As a result, fetching
and storing all registers could yeild better overall performance due
to command latency.  I saw this doing inferior function calls with
powerpc-eabi-gdb when I added support for P command packet to our
debug stub.

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

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

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

Whether register numbers vs. byte offsets and lengths are used is not
that important.  Although my protocol description used offsets, after
thinking about it a while I think I prefer register numbers.  Numbers
are already used in the P command packet, and they avoid any issues
with ranges that contain only parts of registers.

I would think that using new command packets would be the fastest way
to accomplish what you want.  You won't have to autonegotiate whether
a debug stub's 'g' command supports a register range.  

Regardless of whether this is implemented as a new command or as a
extension of the 'g' command, I believe it should always specify a
register range.  If you need to fetch a single register, send a range
where that register is both the start and end point; or implement the
'p' command --- fetch single register.

IMO whether you have a day or a year to implement this change has no
bearing on whether a change to the remote protocol should be made.
Every protocol change has a permanence that goes far beyond today's
deadlines.  Far too many changes have been made to the protocol
without full consideration.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Wed Mar 22 23:53:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>, "J.T. Conklin" <jtc@redbacknetworks.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Remote protocol extension for register ranges
Date: Wed, 22 Mar 2000 23:53:00 -0000
Message-id: <38D9CADE.2FF02871@cygnus.com>
References: <38D8CFA4.C3535C93@redhat.com>
X-SW-Source: 2000-03/msg00311.html
Content-length: 3795

Fernando Nasser wrote:
> 
> Presently, the remote protocol can only read all registers of a target.
> This is OK for the context registers (the ones that are saved by the OD
> on a context switch) but this is a serious limitation for machines that
> have lots of additional registers.  It is just not feasible to read them
> all at every "g" packet.
> 
> I would like to add parameters to the "g" packet.  Something similar has
> been proposed before -- the only difference is that I would like the
> parameters to be a register number or a register number range range.
> 
> For instance:
> 
> g82      Reads register 82
> g31-40   Reads registers 31-40
> 
> Gdb would test for the acceptance of these types of packets by the stub
> and fall back to the less efficient form if not (like it does for "P"
> packets).
> 
> I really need this feature as do other people that are dealing with one
> of the numerous microprocessors that have too many extra registers.  And
> it is becoming quite urgent now.
> 
> What is the current thinking about this?  Are there other proposals I am
> not aware of?  What are the maintainers position?

FYI, I had two potential ideas in mind.  Which I prefer depends on the
target I'm hacking on.

1.	gG like mM

	Treat the target register file like
	a separate section of memory.

	Without arguments, gG would transfer
	the first few registers.

	With arguments (offset, length) a
	sub section of the register file
	could be transfered.

	If read section was supported, write
	section had to also be supported.

	The first obvious optomization
	would be to read a packet of registers
	when ever a single register was
	requested.

	The problem is that the data
	is very raw.  Embedded hardware
	stores registers in target byte-ordered
	register files.  Remote simulators
	and ICEs like to handle host
	ordered structures.  That raw target
	offset would have to be maped onto
	a sequence of host array elements.


2.	like pP

	The second option would be to
	extend/fix the pP packets (or
	a successor) so that they could
	take a range of registers
	and would use *NETWORK* byte
	ordering.

	Such a system would be good
	for small register transfers
	It could certainly be taught
	to pull in a range of registers
	when only one is asked for.
	The target could even be
	given that freedom: Register
	six please; Certainly, along
	with registers 0..5, 7..9.

	It would be more natural to
	simulators, ICEs and the like
	where the raw data tends to
	come in host structured chunks.

	I guess I could also live with
	pP just being extended.

	Be wary of ``-''.  In some
	situtations the stub can parse it
	as a negative number.


Refering to follow-on threads^D^D^D^D postings:

I note the gG proposal above is like J.T.s ``Y'' proposal - perhaphs
J.T.s posted his suggestion before and I've just picked it up :-/ 
W.R.T. detecting support in the ``gG'' packet, provided the fetch works,
the send would have to work.

The idea to include the ``context'' (J.T.s word) in the request is
interesting.  At present, switching ``contexts'' implicitly switches
both the address space and the register file.  We'd need to figure out
if all commands should take that.  J.T. Have you ever thought of a cpu
as a context?  Considered the possibility of different contexts having
different architectures?

When it comes to:
        It might be convienent to have separate (but potentially
        overlapping) register files for integer registers, floating
        point registers, system registers, miscellaneous registers,
        etc.
I think the register file should contain the raw minimum (no
overlapping).  GDB has to get its act to gether and better handle
overlapping registers.
	
What would I suggest?  Both of course .... :-)  They are solving
different problems.

	Andrew
From guo@cup.hp.com Thu Mar 23 11:53:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: gdb@sourceware.cygnus.com
Subject: gdb.gdbtk tests
Date: Thu, 23 Mar 2000 11:53:00 -0000
Message-id: <Pine.LNX.4.10.10003231245280.9146-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-03/msg00312.html
Content-length: 565

These tests apparently require top level tk/, tix/, itcl/, and libgui/
(the Cygnus GUI) components be present in the source tree (per
gdb/testsuite/lib/gdb.exp (gdbtk_start)).  Will these components be part
of public tree any time soon?

Besides, it's better to have a sanity check routine testing all
dependencies before even trying gdb_compile, like the skip_hp_tests one.

Some codes like below will be better:

set path [file join <whatever path>]
if ![file isdirectory $path] {
   perror <error message>
   return 1 (or exit 1)
}

- Jimmy Guo, guo@cup.hp.com

Re: Remote protocol extension for register ranges

[Fernando Nasser]

"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

Re: Remote protocol extension for register ranges

[J.T. Conklin]

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

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.

Adding parameters to the "G" command packet is more troublesome ---
the register values immediately follow the command character.

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>

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.

For amusement purposes only, I've enclosed the store and fetch
sections from the specification I've been writing for a replacement
remote protocol.  Other than the register ranges being specified by
offset and length, it's pretty much the same as the above.

        --jtc


4.1 REGISTER FETCH

input:
	context_t	id;
	int		offset;		offset within register data
	int		length;		length of transfer

output:
	int		status;
	char		data[];

This command may yeild unpredicable results if context <id> has not
been suspended.

issues:
	This assumes a single flat address space for all registers.
	It might be convienent to have separate (but potentially
	overlapping) register files for integer registers, floating
	point registers, system registers, miscellaneous registers,
	etc.  

        For example, one register file could contain the PC, FP, SP,
        and whatever other registers are needed on a particular
	architecture for GDB after a signal/exception/breakpoint
	event.  This would solve the problem of what to return in 
	those events.


4.2 REGISTER STORE

input:
	context_t	id;
	int		offset;		offset within register data
	int		length;		length of transfer
	char		data[];

output:
	int		status;

This command may cause unpredictable behavior if context <id> has not
been suspended.

issues:
	see also register fetch.


4.3 MEMORY FETCH

input:
	addr_t		address;	address of transfer
	int		length;		length of transfer
	mode_t		mode;

output:
	int		status;
	char		data[length];

description:
	Returns the contents of the memory region at <address> through
	<address> + <length>.

This command may yeild unpredictable results if all contexts which
access this memory region have not been suspended (unless some mutual
exclusion mechanism is employed).

issues:
	should this command take a "address space" argument?  This
	might be useful for I/O space and bus spaces.  If so, should
	registers simply be considered a "space".

issues:
	should this command take a context id argument as well?  This
	might be desirable if different contexts can have different
	memory mappings.


4.4 MEMORY STORE

input:
	addr_t		address;	address of transfer
	int		length;		length of transfer
	mode_t		mode;
	char		data[length];

output:
	int		status;

description:
	Writes data[] at <address> through <address> + <length>

This command may cause unpredictable results if all contexts which
access this memory have not been suspended (unless some mutual
exclusion mechanisms is employed).

issues:
	see also memory fetch.


-- 
J.T. Conklin
RedBack Networks
From insulaner_andi@yahoo.com Sat Apr 01 00:00:00 2000
From: Andreas Kuepper <insulaner_andi@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: building GDB on Cygwin fails
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000311184701.12922.qmail@web3401.mail.yahoo.com>
X-SW-Source: 2000-q1/msg00675.html
Content-length: 2739

Hi there,

I am running a Win98 host system and installed Cygwin
successfully. The building of a GCC cross compiler was
also successfully for a DOS based target system using
DJGPP.

Now I want to install GDB on my host(on Cygwin) and
build it for my DJGPP target. By using the latest GDB
(gdb-20000305.tar.bz2) the configure script works
fine. But when I want to build it, I get the following
error message while 'make' is inside the gdb-folder :

bash-2.02$ make
rm -f gdb.exe
gcc -g        -o gdb.exe main.o libgdb.a   
../bfd/libbfd.a ../readline/libreadline.a
../opcodes/libopcodes.a ./../intl/libintl.a
../libiberty/libiberty.a `if test -r
../libtermcap/libtermcap.a; then echo
../libtermcap/libtermcap.a; else echo -ltermcap; fi`  
  -lm  ../libiberty/libiberty.a -luser32 
libgdb.a(stack.o): In function `frame_info':
/djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/stack.c:952:
undefined reference to `sigtramp_saved_pc'
libgdb.a(blockframe.o): In function
`file_frame_chain_valid':
/djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:48:
undefined reference to `sigtramp_saved_pc'
libgdb.a(blockframe.o): In function `get_prev_frame':
/djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:479:
undefined reference to `sigtramp_saved_pc'
libgdb.a(blockframe.o): In function
`generic_file_frame_chain_valid':
/djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:1276:
undefined reference to `sigtramp_saved_pc'
/djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:1279:
undefined reference to `sigtramp_saved_pc'
/cygdrive/c/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../libtermcap.a(tputs.o):
In function `tputs':
/home/noer/src/b20/comp-tools/devo/libtermcap/tputs.c:72:
undefined reference to `_ctype_'
/home/noer/src/b20/comp-tools/devo/libtermcap/tputs.c:75:
undefined reference to `_ctype_'
/home/noer/src/b20/comp-tools/devo/libtermcap/tputs.c:80:
undefined reference to `_ctype_'
/cygdrive/c/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../libtermcap.a(termcap.o):
In function `tgetent':
/home/noer/src/b20/comp-tools/devo/libtermcap/termcap.c:251:
undefined reference to `_ctype_'
/cygdrive/c/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../libtermcap.a(getcap.o):
In function `cgetnext':
/home/noer/src/b20/comp-tools/devo/libtermcap/getcap.c:686:
undefined reference to `_ctype_'
collect2: ld returned 1 exit status
make: *** [gdb.exe] Error 1
bash-2.02$ 


I really don't know where to search for the fault
***[gdb.exe] Error

Thank you for your help !!

Andreas Kuepper
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region attribute CLI
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003211819.NAA12438@indy.delorie.com>
References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> <200003160944.EAA01842@indy.delorie.com> <5mem9avs45.fsf@jtc.redbacknetworks.com> <5m3dplwjri.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00760.html
Content-length: 585

> >>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
> jtc> Yes, I guess it has been a while, hasn't it.
> jtc>
> jtc> Start at:
> jtc>         http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00168.html
> 
> No comments?

Sorry, you are right.

I think this is a very useful idea.  But as far as I understand, the
information managed by the code you posted needs to be consulted by
other GDB commands, right?  I don't see any code that does that yet.

I'm not saying that this somehow invalidates your code and
descriptions, I just want to be sure I'm not missing anything
important.
From jsm@cygnus.com Sat Apr 01 00:00:00 2000
From: Jason Molenda <jsm@cygnus.com>
To: Assar Westerlund <assar@sics.se>
Cc: gdb@sourceware.cygnus.com
Subject: Re: anoncvs errors?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000209091801.A1546@cygnus.com>
References: <5l7lgez651.fsf@assaris.sics.se>
X-SW-Source: 2000-q1/msg00192.html
Content-length: 465

On Wed, Feb 09, 2000 at 05:34:50PM +0100, Assar Westerlund wrote:
> Hi, I'm getting this error trying to use anonymous CVS to
> :pserver:anoncvs@anoncvs.cygnus.com:/cvs/gdb.
> 
> Sorry, you don't have read/write access to the history file /cvs/gdb/CVSROOT/history
> Permission denied

The repository has moved, use :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src

(although you shouldn't have gotten an error with the old repo quite yet.
I will look in to it.)

Jason
From jimb@cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: [cygnus.gcc] dwarfdump
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npwvnynq1x.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00363.html
Content-length: 675

This may be of interest to anyone working on GDB and using Dwarf 2
debugging information.

------- Start of forwarded message -------
From: jason@cygnus.com (Jason Merrill)
Newsgroups: cygnus.gcc
Subject: dwarfdump
Date: 21 Feb 2000 11:10:17 -0800
Organization: Cygnus Solutions news/mail gateway
Message-ID: <200002211910.LAA17403.cygnus.gcc@yorick.cygnus.com>
To: gcc-local@cygnus.com

FWIW, the SGI dwarf2 printing utility, dwarfdump, is available in

  http://reality.sgi.com/davea/libdwarf1999Dec14.tar.gz

I've built it for Solaris (~jason/.bin/sparc-sun-solaris2.5/dwarfdump) and
linux (/usr/unsupported/bin/dwarfdump).

Jason
------- End of forwarded message -------
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Moving Linux-specific stuff out of i386-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091349.IAA19958@indy.delorie.com>
References: <200003082121.e28LLRu05681@delius.kettenis.local> <1000308222742.ZM8876@ocotillo.lan> <38C7AA6D.5465C647@cygnus.com>
X-SW-Source: 2000-q1/msg00644.html
Content-length: 107

> The 8.3 uniqueness rule definitly still applies.

Should I post a list of files which violate that rule?
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jimb@cygnus.com
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003312323.SAA07185@indy.delorie.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <npya7c6zn7.fsf@zwingli.cygnus.com> <200003221806.NAA14225@indy.delorie.com> <npbt4040t3.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg00849.html
Content-length: 905

> > I seem to be unable to reproduce the problem, at least in a C program:
> > whenever I say "watch foo == bar" (where foo and bar are structs), GDB
> > curses thusly:
> > 
> > 	Structure has no component named operator==.
> > 
> > Am I missing something?
> 
> As Michael points out, structure comparison is broken.  But that
> doesn't change my original point --- that it's perfectly legitimate to
> have `struct value' objects representing structures, which should be
> watched in their entirety.

The current sources do support watching an entire struct, the patches
I sent (and Michael commited) have special provisions for this case.

I asked for an example because I want to look into the problem you
were describing and fix it.  Do you have any other case where this
problem could happen?

If every instance of such a situation is equally broken, then the
users won't miss this functionality ;-).
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: annotate.texi
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091254.HAA19889@indy.delorie.com>
References: <38C74298.B562FDD1@cygnus.com> <200003070832.DAA14451@indy.delorie.com>
X-SW-Source: 2000-q1/msg00640.html
Content-length: 1098

> > Is there any reason why annotate.texi shouldn't be @include'd by
> > gdb.texinfo and be part of the manual?  Right now, "set annotate" is
> > not documented at all, and annotate.texi seems to be just what the
> > doctor ordered...
>
> I just wonder if we want to encourage its use :-)

Any user who types "gdb --help" will see the --annotate switch
advertised, and will want to know what that does.  Without
annotate.texi in the manual, this switch cannot be documented
properly.  The same goes for the "set annotate" command.  I think
undocumented features should be generally avoided.

Here's a case in point.  I'm going through the test suite trying to
make sure the DJGPP version passes all the tests.  When I bumped into
the test which tests annotations, I wanted to know what does that
command do.  Naturally, I looked it up in gdb.info, and when that
failed in gdbint.info.  You can guess what I found ;-).

In other words, undocumented features in the long run haunt
maintainers as well.

If we want to discourage use of --annotate, we can say that explicitly
in the manual.

Comments?
From fnasser@redhat.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B69A2A.ED2DC6F3@redhat.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com>
X-SW-Source: 2000-q1/msg00418.html
Content-length: 962

Andrew Cagney wrote:
> 
> It's more a question of should the endianess have changed between
> releases or should it have been little-endian anyway.  Not my problem
> :-)
> 

I inherited this one :-)

But you are right, this will at least require an entry in the NEWS, as
it alters some previous behavior.  *If* the arm users in the list decide
that the default should be little-endian.  It does seem reasonable and
if the file command straights it out, only the load users would have to
care (but they are more aware of these issues, and can always have the
set endian on their .gdbinit).

It is a shame that Angel is so buggy.  The return code should
appropriately indicate the endianess of the target  --  it would be a
nice feature to use :-(

-- 
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 leisner@rochester.rr.com Sat Apr 01 00:00:00 2000
From: "Marty Leisner" <leisner@rochester.rr.com>
To: shebs@apple.com
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com, leisner@rochester.rr.com
Subject: Re: Should GCC tell GDB about its optimizations? 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003040446.XAA04330@rochester.rr.com>
References: <38C051C3.260D666B@apple.com>
X-SW-Source: 2000-q1/msg00533.html
Content-length: 3255

Yes...!!!

I proposed something like this years ago...I almost hacked up
gcc to put this in (I think I started...)

It is incredibly useful in the real world to encapsulate what
compiler flags were used in the binary (essentially the gcc command
line with preprocessor flags).

I just compiled a trivial C program with -O3 to see..

The .s file has
  .ident  "GCC: (GNU) 2.95.2 19991024 (release)"

Is there a way for nm to decode this?  (strings can show it, 
but its pretty meaningless in the binary).

For example:
...
GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
GCC: (GNU) 2.95.2 19991024 (release)
GCC: (GNU) 2.95.2 19991024 (release)
GCC: (GNU) 2.95.2 19991024 (release)
GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
....

I don't know how to take apart elf binaries off the top
of my head, but I assume there is information someplace encoded
to match this up with specific files.

gdb doesn't have to warn, but you should be able to use a tool
to figure this out.

Marty Leisner


Stan Shebs <shebs@apple.com> writes  on Fri, 03 Mar 2000 15:58:59 PST
     > I'm sure this subject has come up before, but I don't remember any
     > consensus...
     > 
     > In the process of finishing Mac OS X, Apple has hundreds of engineers
     > beating on GCC and GDB every day.  The system has literally hundreds
     > of subcomponents; everything from the kernel to speech output to Hebrew
     > font support (sort of like a Linux system preloaded with everything
     > you can find on freshmeat :-) ).  By default, everything is built with
     > optimization turned on.  While an engineer can turn off optimization
     > for a specific bit of code, it's not practical to build an entire system
     > with optimization turned off.  So in practice any single program 
consists
     > of a combination of optimized and unoptimized code.
     > 
     > Ideally of course, GCC would issue lots of amazingly detailed debug 
info,
     > and GDB would use it to reconstruct and report program state just as the
     > programmer expects to see it.  But today, the result is just lame; 
hackers
     > trying to debug get lots of squirrelly behavior from GDB.  The problem 
is
     > that they don't know whether the randomness is due to bugs in the 
program,
     > or to the effect of the optimizer.  So the suggestion came up to have 
GCC
     > issue debug info stating what optimizations have been applied to a file,
     > and to have GDB report that information per-function, so that users 
could
     > lower their expectations appropriately.
     > 
     > Although my first reaction was to say "bleah", upon reflection I 
wondered
     > if I was too easily dismissing the concerns of real users of the tools.
     > This sort of thing routinely confuses users; even with years of GNU
     > experience, I still find myself being caught by surprise because I've
     > forgotten that part of the code was optimized.  A simple warning from 
the
     > debugger would have saved me some time and trouble.
     
     > If there's consensus that this would be a worthwhile addition, I'll
     > work up a specific design and publish it.
     > 
     > Stan