From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: jimb@cygnus.com Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: ST(i) and MMj Date: Wed, 08 Dec 1999 01:46:00 -0000 Message-id: <199912080946.EAA05898@mescaline.gnu.org> 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> X-SW-Source: 1999-q4/msg00476.html > > * 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, ®isters[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 To: Eli Zaretskii 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: 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> 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, ®isters[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 Cc: Steven Johnson , 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> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <384DAE26.241BCE2B@cygnus.com> X-SW-Source: 1999-q4/msg00478.html Content-length: 3061 >>>>> "Andrew" == Andrew Cagney 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 To: jtc@redback.com Cc: Steven Johnson , 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> <199911231303.IAA01523@mescaline.gnu.org> <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 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 [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 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> <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> 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 To: gdb@sourceware.cygnus.com Subject: licensing issues Date: Thu, 09 Dec 1999 08:32:00 -0000 Message-id: 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