Re: ST(i) and MMj

[Eli Zaretskii <eliz@gnu.org>]

> >   * Change functions that read and write registers from/to memory to
> >     handle the MMX registers specially by looking at the appropriate
> >     ST(i) register instead.
> 
> Which functions would these be, exactly?
> 
> On the i386, both variable references and direct register references
> (like $eax) go through (via a torturous chain of calls)
> read_register_gen, which just reaches directly into the register file.

Okay, let's look at read_register_gen (I removed the irrelevant
clutter):

    void
    read_register_gen (regno, myaddr)
	 int regno;
	 char *myaddr;
    {
      if (!register_valid[regno])
	target_fetch_registers (regno);
      memcpy (myaddr, &registers[REGISTER_BYTE (regno)],
	      REGISTER_RAW_SIZE (regno));
    }

This can be changed like this:

  1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
     REGISTER_BYTE so that for MMX registers it goes to the data of
     the according ST(i) register using the current TOS.

  2) target_fetch_registers then will actually bring the value of the
     appropriate ST(i) register when passed a regno of an MMX
     register.

> I think I'd need to see a very specific explanation of how to do this,
> showing which functions to change, etc.  Talking about it at a higher
> level is just getting confusing.

You are right.  All functions in findvar.c that deal with registers
will have to be inspected, but just by looking at these functions, it
seems like a smart enough definition of REGISTER_* macros will do most
of the work.  We might also need to update register_valid[] for an MMX
register together with its corresponding ST(i) register, though; this
might require to introduce a target-dependent function to update
register_valid[] when a given register REGNO is fetched (but code that
reads register_valid[] can be left intact).

If it will help, I can try to make these changes, once the MMX support
for x86 is in place.
From jimb@cygnus.com Wed Dec 08 02:25:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Wed, 08 Dec 1999 02:25:00 -0000
Message-id: <npogc1afwn.fsf@zwingli.cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <38478987.EECEEBF@cygnus.com> <199912061134.GAA16617@mescaline.gnu.org> <npk8msaqoo.fsf@zwingli.cygnus.com> <199912080946.EAA05898@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00477.html
Content-length: 2381

> Okay, let's look at read_register_gen (I removed the irrelevant
> clutter):
> 
>     void
>     read_register_gen (regno, myaddr)
> 	 int regno;
> 	 char *myaddr;
>     {
>       if (!register_valid[regno])
> 	target_fetch_registers (regno);
>       memcpy (myaddr, &registers[REGISTER_BYTE (regno)],
> 	      REGISTER_RAW_SIZE (regno));
>     }
> 
> This can be changed like this:
> 
>   1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
>      REGISTER_BYTE so that for MMX registers it goes to the data of
>      the according ST(i) register using the current TOS.
> 
>   2) target_fetch_registers then will actually bring the value of the
>      appropriate ST(i) register when passed a regno of an MMX
>      register.

I thought we had posited that the MMX registers, when stored in
memory, have zero length --- i.e., REGISTER_RAW_SIZE (MM0_REGNO) == 0
--- to avoid overlap problems in loops.


> > I think I'd need to see a very specific explanation of how to do this,
> > showing which functions to change, etc.  Talking about it at a higher
> > level is just getting confusing.
> 
> You are right.  All functions in findvar.c that deal with registers
> will have to be inspected, but just by looking at these functions, it
> seems like a smart enough definition of REGISTER_* macros will do most
> of the work.  We might also need to update register_valid[] for an MMX
> register together with its corresponding ST(i) register, though; this
> might require to introduce a target-dependent function to update
> register_valid[] when a given register REGNO is fetched (but code that
> reads register_valid[] can be left intact).
> 
> If it will help, I can try to make these changes, once the MMX support
> for x86 is in place.

I'm sure we could make something work.  What concerns me is that it be
reasonable enough that people who are not familiar with the x86 won't
write code that breaks it.  Having REGISTER_RAW_SIZE be zero is on the
edge, and now we're positing further things to maintain register_valid
...

I have another proposal in mind which is more work, and more invasive,
but is more generally useful.  It would allow us to solve this
problem, and implement base-relative FP register numbering (as
discussed long ago on the EGCS list), and deal with some others I
think I remember hearing about over the years.  I'll describe it here
soon.
From jtc@redback.com Wed Dec 08 15:54:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Wed, 08 Dec 1999 15:54:00 -0000
Message-id: <5mbt81ugxx.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <384DAE26.241BCE2B@cygnus.com>
X-SW-Source: 1999-q4/msg00478.html
Content-length: 3061

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
jtc>
jtc> These are all great, but I'm not sure how much can been within the
jtc> confines of the existing protocol.

Andrew> As a vague suggestion of a ``five year'' gdb-protocol plan:
Andrew>
Andrew> 	v2.0: Formalize the lower layers (transport, ...?)
Andrew> 		(Where's my AST networks book :-) and address
Andrew> 		issues such as reliability.
Andrew>
Andrew> 		The command set would remain the same - warts
Andrew> 		and all.
Andrew>
Andrew> 	v3.0: Look at the actual gdb command set

Mine has been at my side for the last week or so, in the vain hope
that I'd have a few minutes to spare to participate in this thread.
I've been chastised a few times in the last week about having the
'obsolete' second edition.  :-)

I think that formalizing the existing packet transport is essential.
To move forward, we must first know where we stand.  Even if we are
not able fix all of the problems (because doing so would require
incompatible changes to the framing mechanism, etc.), we should be
able to come up with a list of best or recommended practices and
ensure that remote.c and the sample stubs adhere to them.

Andrew> If the two can be separated then, there is some hope of being
Andrew> able to move forward.

If the two layers can can be separated, I see no technical reason that
changes to the command layer be delayed until changes to the transport
layer are completed.  In an ideal world, work on both could progress
in parallel.  However, I suspect that the people interested in
improving the transport layer are the very same people interested in
improving the command layer.  Thus sequencing the projects is probably
the right thing to do.

Andrew> The alternative, as always, is to start again from scratch.

I've been convinced that a new protocol is needed for the last year or
so.  At the same time, I am glad I didn't start designing/implementing
one at that time.  I believe the likely result of such an effort would
have been unsuccessful.  

During the last year, besides complaining about the existing RDP :-),
I've been able to put a lot more thought into the limitations of the
RDP and how I'd address them.  I feel I'm in a much better position 
to do it right now than I was then.

Andrew> (As for the mini-telnet, if someone would like to propose a
Andrew> decent telnet extenstion to the protocol then, I'm all ears)

If we change the lower levels, this becomes easy.  Each packet would
have a 'protocol' field which would indicate which upper level stack
would handle the packet.  One value would indicate be a GDB command/
response protocl.  Another would be a Link Control Protocol used to
establish/negotiate link layer options (8 vs. 7 bit, hex vs. base64
encoding, RLE compression, etc.).  

To replace minitelnet, a lightweight 'protocol' to transfer console
i/o to and from the target.  With a bit more effort, a virtual i/o
scheme could be invented so the target could use the host's file-
system and devices.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Wed Dec 08 20:56:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Wed, 08 Dec 1999 20:56:00 -0000
Message-id: <384F3633.B395BFB1@cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00479.html
Content-length: 1604

"J.T. Conklin" wrote:

> Andrew> If the two can be separated then, there is some hope of being
> Andrew> able to move forward.
> 
> If the two layers can can be separated, I see no technical reason that
> changes to the command layer be delayed until changes to the transport
> layer are completed.  In an ideal world, work on both could progress
> in parallel.  However, I suspect that the people interested in
> improving the transport layer are the very same people interested in
> improving the command layer.  Thus sequencing the projects is probably
> the right thing to do.

That is a very good point.  There is definitly room for overlap.  Once
the hair between the commands and the transport are separated, things
can move more freely.

> Andrew> (As for the mini-telnet, if someone would like to propose a
> Andrew> decent telnet extenstion to the protocol then, I'm all ears)
> 
> If we change the lower levels, this becomes easy.  Each packet would
> have a 'protocol' field which would indicate which upper level stack
> would handle the packet.  One value would indicate be a GDB command/
> response protocl.  Another would be a Link Control Protocol used to
> establish/negotiate link layer options (8 vs. 7 bit, hex vs. base64
> encoding, RLE compression, etc.).

This is starting to sound like IP:-)  Just as long as it isn't as heavy
:-)

> To replace minitelnet, a lightweight 'protocol' to transfer console
> i/o to and from the target.  With a bit more effort, a virtual i/o
> scheme could be invented so the target could use the host's file-
> system and devices.

Agreed.

	Andrew
From ac131313@cygnus.com Thu Dec 09 00:11:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region attributes
Date: Thu, 09 Dec 1999 00:11:00 -0000
Message-id: <384F63D7.295BD224@cygnus.com>
References: <5m3dux68hc.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00480.html
Content-length: 1839

"J.T. Conklin" wrote:

Sorry, this just sat in my in tray :-(

> Synopsis:
>     (gdb) mem <start address> <end_address> [attribute ...]
> 
> Attributes:
>     rw - memory is read/write (default)
>     ro - memory is read only, GDB will refuse to issue a write
>          command.
>     wo - memory is write only, GDB will refuse to issue a read
>          command.
> 
>     8,16,32  - access memory in X sized operations
> 
>     hwbreak  - GDB internal breakpoints use hw breakpoints
>     swbreak  - GDB internal breakpoints use sw breakpoints (default)
> 
>     cache    - enable host-side caching
>     nocache  - disable host-side caching (default)
> 
> Examples:
>     (gdb) mem &start &etext ro cache
>     (gdb) mem &uart_base &uart_base + 0x0f 8

J.T. as a representation of the actual memory, you may want to look at
what the simulators are using (sim/common/sim-core.c,
sim/common/sim-memopt.c).  The code started out with a simile model as
you've described but ended up with a slightly more complex
representation of target memory.  It is very much a reflection of the
tricks that hardware engineeers like to play with address decode lines
:-)

Briefly:

	o	The regions can be layered.
		That way it is clear what happens
		if two regions overlap.

		This reflects memory with ``holes''

	o	Memory regions can be shaddowed/aliases
		Region 0x100..0x200 also at 0x1100..0x1200
		This reflects how some address lines
		are not decoded.

	o	Similarly, memory can be repeated
		across a region.  The same block
		appearing at 0x0..0x10, 0x10..0x20,
		and so on for an entire 1mb.

Hmm,  perhaphs, instead of something like this where the user specifies
constants mem should take an equation that returns the relevant
attributes. That way the user can built up an arbitrary set of rules
about what memory can be accessed.

	Andrew
From eliz@gnu.org Thu Dec 09 02:29:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Thu, 09 Dec 1999 02:29:00 -0000
Message-id: <199912091029.FAA13387@mescaline.gnu.org>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <38478987.EECEEBF@cygnus.com> <199912061134.GAA16617@mescaline.gnu.org> <npk8msaqoo.fsf@zwingli.cygnus.com> <199912080946.EAA05898@mescaline.gnu.org> <npogc1afwn.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00481.html
Content-length: 1006

> >   1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
> >      REGISTER_BYTE so that for MMX registers it goes to the data of
> >      the according ST(i) register using the current TOS.
> > 
> >   2) target_fetch_registers then will actually bring the value of the
> >      appropriate ST(i) register when passed a regno of an MMX
> >      register.
> 
> I thought we had posited that the MMX registers, when stored in
> memory, have zero length --- i.e., REGISTER_RAW_SIZE (MM0_REGNO) == 0
> --- to avoid overlap problems in loops.

The above still avoids overlap, by keeping only a single copy of each
FPU register in the register file.  However, the zero-size definition
isn't useful when you want to read the value of an MMX register from
the register file.  So I changed my mind ;-).

> What concerns me is that it be reasonable enough that people who are
> not familiar with the x86 won't write code that breaks it.

Hiding the complexity behind REGISTER_BYTE should prevent this.
From qqi@world.std.com Thu Dec 09 08:32:00 1999
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: licensing issues
Date: Thu, 09 Dec 1999 08:32:00 -0000
Message-id: <Pine.SGI.3.95.991209111558.13465A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00482.html
Content-length: 1037

Hi, 

I am developing replacement/enchancement for gdbserver. The major 
difference is that it will allow to debug not only process on 
the remote machine, but it also allows to debug an embedded system
attached to the remote machine, plus it has support for bigger 
amount of recent quirks.

I have a question  related to GPL. I posted it earlier and I got no 
response. I am posting it again in a hope that ones in the know,
would respond. I would like to allow a possibility to attach
debuggers with proprietary interfaces (e.g macraigor wiggler).

I would like to publish my work under GPL, however, it is unclear 
to me whether my intention to allow proprietary stuff (in the form
of shared libs) in is in line with GPL. In my view it is: I put 
.h file defining interface into public domain and there is no 
need for anybody to use or link any other part of GPL'ed code in
proprietary library: there are only three callback functions, which 
are passed as pointers through the API, and no data sharing.

Thanks,

Aleksey