Re: ST(i) and MMj

[Andrew Cagney <ac131313@cygnus.com>]

Eli Zaretskii wrote:
> 
> > >   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.

Only to confuse the poor person that has to fix a bug in REGISTER_BYTE
:-)
I think Jim's point is important.  The current semantics of this macro
is fairly straight forward - return the offset of the byte in a raw
buffer.  Compare that to some of the other target macro's such as
REGISTER_NAME / REGISTER_NAMES.

There's an oportunity here to eliminate a problem with GDB for all
targets.

	enjoy,
		Andrew
From jtc@redback.com Fri Dec 10 12:42: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: Fri, 10 Dec 1999 12:42:00 -0000
Message-id: <5mpuwetto7.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> <384F3633.B395BFB1@cygnus.com>
X-SW-Source: 1999-q4/msg00487.html
Content-length: 2116

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> 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.).

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

I was thinking more along the lines of something between SL/IP and
PPP.

WRS uses SL/IP with a shim IP and UDP layer, on top of which they run
their SunRPC based protocol.  It's not a full stack by any means, but
it's enough of one that you can connect a target to a terminal server
(or configure your host to run SL/IP) and connect to it over the
network.  The disadvantage of this is that it adds substantial packet
overhead (IP and UDP headers) and target code to implement the shim
network layers.

SL/IP by itself doesn't buy us much, since it's really just a packet
framing mechanism.  In many ways, it is inferior to the existing RDP
framing.  For example, packet integrity (checksums) is left to upper
network layers.

PPP is more complicated.  Although it should be possible to have RDP
as one of PPP's encapsualted protocols (like IP, IPX, etc.), I don't
think we'd actually want to do so.  I suspect that GDB would have to
implement a host side stack as well, even on hosts that support PPP,
in order for GDB to tunnel RDP.  Of course, the target would need a
PPP stack as well.

Even without those problems, It's not clear that PPP is appropriate.
PPP leaves reliable transport to the upper layers; and that's one of
the problems we're having with the existing RDP.  

So, what we want is something with the simplicity and efficiency of
SL/IP, with link layer configuration/negotiation and multi protocol
support of PPP, plus a reliable transport shared by all protcols (RDP
commands, virtual I/O, etc.)

        --jtc

-- 
J.T. Conklin
RedBack Networks
From qqi@world.std.com Fri Dec 10 19:29:00 1999
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: another bug in remote.c
Date: Fri, 10 Dec 1999 19:29:00 -0000
Message-id: <Pine.SGI.3.95.991210221737.22433A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00488.html
Content-length: 555

Hi, 

I got another bug. This time I do not know how to fix it. 
It is possible to get into following sequence of of events:



gdb:       $m4000ab70,c8#22        -- asks for 200 bytes of memory
stub:      $<400 chars>#XX         -- stub responds correctly, packet 
                                      length 404 bytes
gdb:       Remote packet too long  -- gdb unhappy


I suspect that PBUFSIZ should not be used to determine
max_buf_size in remote_read_bytes(). It seems like there are
more places where similar problem may occur.


Thanks,

Aleksey