From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Eli Zaretskii Cc: jimb@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: ST(i) and MMj Date: Fri, 10 Dec 1999 05:51:00 -0000 Message-id: <3851050E.2894F410@cygnus.com> References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <199912010821.DAA27130@mescaline.gnu.org> <38478987.EECEEBF@cygnus.com> <199912061134.GAA16617@mescaline.gnu.org> <199912080946.EAA05898@mescaline.gnu.org> <199912091029.FAA13387@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00486.html 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 Cc: Steven Johnson , 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> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <384F3633.B395BFB1@cygnus.com> X-SW-Source: 1999-q4/msg00487.html Content-length: 2116 >>>>> "Andrew" == Andrew Cagney 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 To: gdb@sourceware.cygnus.com Subject: another bug in remote.c Date: Fri, 10 Dec 1999 19:29:00 -0000 Message-id: 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