* Re: none [not found] ` <199911251715.MAA09225@mescaline.gnu.org> @ 1999-11-30 10:20 ` Jim Blandy 1999-12-01 0:21 ` ST(i) and MMj Eli Zaretskii 0 siblings, 1 reply; 8+ messages in thread From: Jim Blandy @ 1999-11-30 10:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gdb > > For register views, yes, we can do anything we please. However, when > > the compiler places a register in an MMX register value, we still get > > an old-fashioned symbol with a LOC_REGISTER. Register views don't > > come into it. As long as we only have a LOC_REGISTER, we don't have > > enough information to do the job right. > > I probably don't understand how this works. How is the LOC_REGISTER > thing different from the case where the user specifies a certain > register (e.g., when the user wants to change its value)? At any > given point in a debugging session, GDB knows what is the current TOS, > and therefore can map any MMX register to the corresponding ST(i), > right? If a symbol's address class (`aclass') is LOC_REGISTER and its value is N, then GDB assumes the variable's value occupies register N. It uses REGISTER_BYTE(N), REGISTER_RAW_SIZE(N), etc. to access that symbol's value. We can't assign distinct register numbers to %st(0) and %mm0, for reasons discussed previously: GDB can't cope with two distinct register numbers referring to the same bits in the register file. We can't use the same register numbers for %st(0) and %mm0, since they're only the same bits when TOS is zero. So there is no possible register numbering which allows us to refer to both %st(0) and %mm0. Therefore, %st(0) and %mm0 cannot both be `registers', as far as GDB is concerned. From shebs@cygnus.com Tue Nov 30 13:16:00 1999 From: Stan Shebs <shebs@cygnus.com> To: cgf@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 13:16:00 -0000 Message-id: <199911302116.NAA00394@andros.cygnus.com> References: <81i3de$kj6$1@cronkite.cygnus.com> X-SW-Source: 1999-q4/msg00367.html Content-length: 1070 From: cgf@cygnus.com (Chris Faylor) Date: 25 Nov 1999 01:29:18 GMT When I added thread support for Windows I wished for an additional field or two in gdb's thread structure which would have allowed me to store extra OS specific state about a thread. It would only have to be an opaque void * pointer of use only to the target. This would have saved a fair amount of head-standing in win32-nat.c. But, I don't think that this is exactly what you're talking about. Having some kind of extensible way to query and report thread information would be nice. At the very simplest an additional target vector could be supplied which returned extra information to tack onto info thread output. Actually, this is a perfect example, and yes, the implementation would use an additional target vector entry. This isn't the first time the desire has come up for additional info about threads, but for natives the solution is easy - just add a system-specific command to foo-nat.c. This still loses for cross-debugging though. Stan From shebs@cygnus.com Tue Nov 30 13:55:00 1999 From: Stan Shebs <shebs@cygnus.com> To: jlarmour@cygnus.co.uk Cc: msalter@cygnus.com, jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 13:55:00 -0000 Message-id: <199911302155.NAA11699@andros.cygnus.com> References: <199911250727.HAA31443@peshwari.cygnus.co.uk> X-SW-Source: 1999-q4/msg00368.html Content-length: 3113 Date: Thu, 25 Nov 1999 07:27:38 GMT From: jlarmour@cygnus.co.uk (Jonathan Larmour) >Perhaps the eCos developers' judgment is flawed, but they certainly >preferred adding a packet over the alternative of encoding eCos >internals into GDB, whether it was as scripts or C code. But this >decision was made a couple years ago; I'll bring it up with them >again, perhaps they've changed their minds about this point. Nope :-). At least not unless the scripts can adapt when the kernel thread structure can change from program to program. Hard-coded C is right out. It's feasible to enhance GDB scripting to do this right, but it certainly isn't possible now. And then there are the other problems like it not being usable from anything other than the CLUI. Thanks for the info, I didn't even think about the effect of eCos configurability. But it's the performance that's the real killer. Remote debugging over wet string is slow enough, but add in the latency of script interpretation, and having to synchronously query each item of thread state with separate memory reads, and you have an unusable system. eCos is only requesting the ID, name, and state in addition to the normal info, and the info is returned in one packet per thread. But it takes around 1 second per thread with a 38400bps link. It's not nice, but it we really must not do anything to make it slower, which scripting would do a lot. I think this is all optimizable - nobody has spent any time on improvements since the original implementation. We're certainly not picking up 4K of useful info about each thread... NB Other OS's may well find it very difficult to export internal structures without actually having large sections of the OS itself compiled with debug info, which may well be unacceptable. eCos doesn't mind as we're open source, but I don't think we should discriminate. The type information encoded in the debug info is much more interesting than the actual symbols of course. While it's a problem, it's not really very serious, because you can pick up the info just by including some sort of <thread_struct.h> in your app somewhere. Often you have to do that anyway just to use threads in the first place. Still, enough users will forget this, or experience the linker doing symbol GC, or whatever, so it will make scripts seem unreliable. I think what is required is to draw up a list of all the thread concepts we already know that users would want to know about: thread ID, name, priority, state, stack frame at least. A target stub may support any or all of these. The name makes sense as a general concept - Tom Tromey points out that it's useful for Java too - and stack frame is implicit in the thread's register set. Priority and state are rather variable in nature, which I would prefer to have them be glommed into a single string. As a corollary, I'm not too keen on building in an elaborate bitmap mechanism, but there are other ways to reduce bandwidth, I'll think about the issue a bit more. Stan From shebs@cygnus.com Tue Nov 30 14:46:00 1999 From: Stan Shebs <shebs@cygnus.com> To: msalter@cygnus.com Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 14:46:00 -0000 Message-id: <199911302246.OAA28180@andros.cygnus.com> References: <199911281854.NAA20537@msalter2.cygnus.com> X-SW-Source: 1999-q4/msg00369.html Content-length: 3949 Date: Sun, 28 Nov 1999 13:54:42 -0500 From: Mark Salter <msalter@cygnus.com> > Perhaps the eCos developers' judgment is flawed, but they certainly > preferred adding a packet over the alternative of encoding eCos > internals into GDB, whether it was as scripts or C code. I wouldn't say their judgement is flawed. I would agree with their decision if debugging using the remote protocol were the only debugging environment to be considered. But you erect a strawman, here. I never suggested encoding eCos (or any other) OS internals in gdb. If the info is encoded in a script that always ships with GDB, then from my point of view, it's part of GDB. Sometimes it's unavoidable; GDB sources include all kinds of gory detail about AIX, HP-UX, etc, some of which was acquired by reverse engineering and experimentation. But we only want to do that if absolutely necessary; if there is a defined API or protocol, we would much rather use that instead. But this > decision was made a couple years ago; I'll bring it up with them > again, perhaps they've changed their minds about this point. I wasn't aware that the eCos group was the sole arbiter of this issue. Of course not! I'm the sole arbiter. :-) But as an open-source RTOS that uses GDB as its primary debugger, eCos is an important client, and it's worth considering how best to accommodate it, and how that used to improve OS support in general. > It's certainly always possible to write something that works for a > particular situation. My concern is that we're supposed to be > supplying something that works consistently for users across both GDB > and OS revs. GDB shouldn't have to worry about OS revs. I'm assuming that the script to extract thread info from a target is provided and maintained by the OS vendor, not the gdb maintainers. So each vendor provides a script with a different name, and it has to also get a different name whenever the OS changes, and the user has to know which script to use. Seems less desirable than an "info threads" or "info extra" that has the same usage for everybody. > A gui can do what a gdb script does and use memory read operations > to get the info it needs. > Which means that each GUI now has to have its own version of the same > thread-groveling script? Sounds like an MxN problem. No, the OS vendor-supplied thread-groveling scripts provide an interface to thread info that can be used from a CLUI or from a GUI. How is the GUI to collect the script's output though? By parsing it? If so, then you have to specify the output format of scripts written by random third parties, not to mention writing the parser. This is getting to be an awful lot of work just to avoid adding ~20 lines to GDB. Certainly if somebody wants to provide all-singing all-dancing OS support, they'll have to do that anyway, but that's OK; I just want GDB to provide a very basic level of thread info support that lets people use it without a lot of work, and that does not preclude adding something more elaborate later on. This solution by definition, only works if you are using the remote protocol. It does not address gdb's debugging interface to simulators. This is a huge deficiency in my opinion. Implementationwise I was going to add a target vector entry per the usual process; the concept of extra thread info is not specific to the remote protocol. Then we can do extra thread info for Win32 if desired, etc. I'm not too concerned about simulators, because I haven't personally seen or heard of any simulators that had an OS implicitly buried in them, such that remote-sim.c had to implement thread methods itself - certainly there are none such in GNU right now. The whole idea involves so many variables that I'd want to hear about the architecture of a real example, before trying to design GDB to accommodate it. Stan From jtc@redback.com Tue Nov 30 15:11:00 1999 From: jtc@redback.com (J.T. Conklin) To: Stan Shebs <shebs@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 15:11:00 -0000 Message-id: <5mr9h74lsx.fsf@jtc.redbacknetworks.com> References: <199911232211.OAA25604@andros.cygnus.com> X-SW-Source: 1999-q4/msg00370.html Content-length: 3390 >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes: jtc> Besides your three suggestions, I prefer a fourth: provide jtc> target specific user defined functions which traverse the jtc> thread table and presents the information in a useful format. jtc> This doesn't bind any knowledge about any particular thread jtc> implementation into GDB; is easily modifyable by the end user jtc> (rather than a GDB hacker) to add, remove, or change the jtc> presentation of thread information; and should not require jtc> any changes to the target. Stan> I didn't mention this option because it has a couple fatal Stan> flaws. I didn't think of these as flaws, as I was thinking along the lines that any info gathering mechanism had to be built on top the existing target primitives, otherwise it would be limited to a small subset of targets. That is what I would consider a fatal flaw. And if you compare the difficulty of implementing data structure groveling code in GDB's C code vs. doing the same in a GDB script, I think the choice is clear. Stan> First, it doesn't work if the OS doesn't have a thread Stan> table. What if the OS calculates it on the fly, or expects the Stan> programmer to choose the location of the table or whatever Stan> structure it is? If the OS computes a thread table on the fly, we should be able to do the same in a GDB script. It may not be pleasant do to so. Stan> Second, it requires a set of symbols. In your VxWorks example, Stan> you manage to have WIND_TCB and activeQHead.pFirstNode available Stan> somehow. I can't justify requiring an OS to expose its private Stan> data structures, nor requiring users to link the definitions of Stan> the data structures into their applications, whether or not the Stan> application uses those structures directly. (There is also a Stan> potential usability problem with getting the compiler to include Stan> unused symbols in an executable.) That's just one example of one way to do it. The point is a target is going to have to expose *some* method of obtaining the thread list. It may be the symbols that make up the list, it may be a function that when called fills in a buffer, etc. If the vendor makes the thread list available at all, there has to be some mechanism of obtaining it. If they don't, a stub will not be able to obtain the same information for a remote protocol extension either. Stan> Third, there's no internal pathway for GUI clients to get the Stan> information and do their own thing with it. In other words, Stan> scripts cannot presently be used to implement any part of a Stan> libgdb API. This probably needs to be addressed. There are many current commands --- primarily those that present target information like info reg --- that should be scripts. There are others where it would be useful to call out to script `hooks'. Stan> An additional non-fatal objection is that GDB's scripting Stan> machinery is too weak to depend on as an integral part of the Stan> debugger. As a language, it's weak. As an implementation, it seems pretty solid. Stan> It's good enough for people to develop scripts for use inhouse, Stan> but imagine trying to manage and distribute dozens of Stan> configuration-specific script files; it would be a disaster. No worse than embedding target specific knowlege into GDB's C files. --jtc -- J.T. Conklin RedBack Networks From jtc@redback.com Tue Nov 30 15:28:00 1999 From: jtc@redback.com (J.T. Conklin) To: jlarmour@cygnus.co.uk (Jonathan Larmour) Cc: shebs@cygnus.com, msalter@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 15:28:00 -0000 Message-id: <5mn1rv4l1e.fsf@jtc.redbacknetworks.com> References: <199911250727.HAA31443@peshwari.cygnus.co.uk> X-SW-Source: 1999-q4/msg00371.html Content-length: 1051 >>>>> "Jonathan" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes: Jonathan> I think what is required is to draw up a list of all the Jonathan> thread concepts we already know that users would want to Jonathan> know about: thread ID, name, priority, state, stack frame at Jonathan> least. A target stub may support any or all of these. The problem is that this is an open ended set of variables, and they are represented with different types in different OSs. For example, to debug problems at different times I've had to look at thread ID, name, priority, inherited priority, state, stack bounds (stack top & bottom, and current stack pointer), number of ticks since task was last scheduled, number of interrupts received while in this task's context, number of times task has be placed on run queue, number of times task has been preemted, number of times task has yielded unconditionally, etc., etc., etc. And that's just my list. Combine that with everyone elses, and it gets out of hand... --jtc -- J.T. Conklin RedBack Networks From jtc@redback.com Tue Nov 30 15:53:00 1999 From: jtc@redback.com (J.T. Conklin) To: Stan Shebs <shebs@cygnus.com> Cc: msalter@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 15:53:00 -0000 Message-id: <5miu2j4jul.fsf@jtc.redbacknetworks.com> References: <199911302246.OAA28180@andros.cygnus.com> X-SW-Source: 1999-q4/msg00372.html Content-length: 1285 >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes: Stan> I'm not too concerned about simulators, because I haven't Stan> personally seen or heard of any simulators that had an OS Stan> implicitly buried in them, such that remote-sim.c had to Stan> implement thread methods itself - certainly there are none such Stan> in GNU right now. The whole idea involves so many variables Stan> that I'd want to hear about the architecture of a real example, Stan> before trying to design GDB to accommodate it. That's just the point. A simulator (or ICE) environment is a blank slate --- just like a random piece of target hardware. It might run eCos, RTEMS, vxWorks, IOS, etc. It does not (and IMO it should not) have any knowlege of the OS running on it. Ideally the same generic embedded GDB should be able to debug all of these OSs. But instead of going through an intermediary debug agent, GDB (or an ICE under GDB's control) can examine and manipulate the targets memory and registers directly. Thus it seems wrong to put OS specific knowledge in the simulator's target vector. It should be at a higher level so that it can use the primitives provided by every target. The same issues are found in examining crash dumps. --jtc -- J.T. Conklin RedBack Networks From shebs@cygnus.com Tue Nov 30 15:57:00 1999 From: Stan Shebs <shebs@cygnus.com> To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 15:57:00 -0000 Message-id: <199911302352.PAA03068@andros.cygnus.com> References: <5mr9h74lsx.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00373.html Content-length: 2691 From: jtc@redback.com (J.T. Conklin) Date: 30 Nov 1999 15:11:26 -0800 I didn't think of these as flaws, as I was thinking along the lines that any info gathering mechanism had to be built on top the existing target primitives, otherwise it would be limited to a small subset of targets. That is what I would consider a fatal flaw. And if you compare the difficulty of implementing data structure groveling code in GDB's C code vs. doing the same in a GDB script, I think the choice is clear. I think there's some confusion here. The extra thread info I'm referring to is already being collected by a special type of packet in the standard protocol. As far as I know only eCos uses that packet, but since it's been in the sources for a year, it's possible that some other OS is using it too. The display of the info is also already written, but it's only in the version of the sources that you can download along with eCos. It does nothing more than printf three additional strings that were received in the special thread packet - and one of those strings is always empty these days. So neither the regular nor the eCos GDB do any groveling of data structures, nor am I proposing such an addition. What I'm proposing is to create an abstract notion of additional thread info, and to regularize its handling, so that if it's appropriate for the target OS to do the dirty work itself, it can, and then GDB simply passes the data through for the user to see. The point is a target is going to have to expose *some* method of obtaining the thread list. It may be the symbols that make up the list, it may be a function that when called fills in a buffer, etc. If the vendor makes the thread list available at all, there has to be some mechanism of obtaining it. If they don't, a stub will not be able to obtain the same information for a remote protocol extension either. If the stub is part of the OS, then it has the ability to collect thread info. In fact, a thread-supporting stub already has to be able to get basic thread info, so it already has a way to collect threads and report them. This is just another example of putting functionality in the stub for the sake of consistency and performance. It's not really any different from having stubs manage breakpoints, watchpoints, searches, or any of the other stub-complicating performance-enhancing changes that have been proposed in the past. I think this one "feels" different in that it addresses higher levels of functionality, but as I've mentioned in a previous message, users want more functionality and more OS support in the debugger, not less. Stan From shebs@cygnus.com Tue Nov 30 15:58:00 1999 From: Stan Shebs <shebs@cygnus.com> To: jtc@redback.com Cc: jlarmour@cygnus.co.uk, msalter@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 15:58:00 -0000 Message-id: <199911302358.PAA03505@andros.cygnus.com> References: <5mn1rv4l1e.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00374.html Content-length: 1427 From: jtc@redback.com (J.T. Conklin) Date: 30 Nov 1999 15:27:57 -0800 >>>>> "Jonathan" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes: Jonathan> I think what is required is to draw up a list of all the Jonathan> thread concepts we already know that users would want to Jonathan> know about: thread ID, name, priority, state, stack frame at Jonathan> least. A target stub may support any or all of these. The problem is that this is an open ended set of variables, and they are represented with different types in different OSs. For example, to debug problems at different times I've had to look at thread ID, name, priority, inherited priority, state, stack bounds (stack top & bottom, and current stack pointer), number of ticks since task was last scheduled, number of interrupts received while in this task's context, number of times task has be placed on run queue, number of times task has been preemted, number of times task has yielded unconditionally, etc., etc., etc. And that's just my list. Combine that with everyone elses, and it gets out of hand... A couple of the values you mention remind me - how is direct thread access supposed to work for a memory-protected OS, for instance for Posix threads on a Unix-type system, say embedded Linux? It would be pretty heinous to try to make scripts call ptrace (or ttrace on HP-UX) directly... Stan From jtc@redback.com Tue Nov 30 16:25:00 1999 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: memory verify Date: Tue, 30 Nov 1999 16:25:00 -0000 Message-id: <5memd74iem.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00375.html Content-length: 1542 I was thinking about the compare-sections command found in remote.c and also adding a 'verify' attribute to my memory region code. We need a target primitive for doing memory verifies. There are three mechanisms that I can think of that can be used for this. Download a chunk of memory and an address and have the target determine whether they are the same; upload a chunk of memory at an address and have GDB perform the comparison; and perform a CRC or strong hash function on both the host and the target and compare the results. The second can be trivially implemented using the target vector's memory read function. However verify performance can be improved if the target supplies either a compare memory or checksum command. I propose the following new verify primitive: /* Verify that memory at GDB address MYADDR and target address MEMADDR are identical. This can be done by downloading the memory region to the target and having it do the comparison; uploading the memory region to GDB and having it do the comparision; using a checksum, cyclic redundency check, or cryptographic hash function; etc. Return value, N, is one of the following: 0 - memory region is not identical. 1 - memory region is identical. */ int (*to_verify_memory) (CORE_ADDR memaddr, char *myaddr, int len); If the target cannot handle a memory region of that SIZE, the function is responsible for breaking it up into chunks. --jtc -- J.T. Conklin RedBack Networks From shebs@cygnus.com Tue Nov 30 16:43:00 1999 From: Stan Shebs <shebs@cygnus.com> To: jtc@redback.com Cc: msalter@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Extra Thread Info Date: Tue, 30 Nov 1999 16:43:00 -0000 Message-id: <199912010043.QAA15210@andros.cygnus.com> References: <5miu2j4jul.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00376.html Content-length: 3034 From: jtc@redback.com (J.T. Conklin) Date: 30 Nov 1999 15:53:38 -0800 >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes: Stan> I'm not too concerned about simulators, because I haven't Stan> personally seen or heard of any simulators that had an OS Stan> implicitly buried in them, such that remote-sim.c had to Stan> implement thread methods itself - certainly there are none such Stan> in GNU right now. The whole idea involves so many variables Stan> that I'd want to hear about the architecture of a real example, Stan> before trying to design GDB to accommodate it. That's just the point. A simulator (or ICE) environment is a blank slate --- just like a random piece of target hardware. It might run eCos, RTEMS, vxWorks, IOS, etc. It does not (and IMO it should not) have any knowlege of the OS running on it. This is misleading, because GDB's basic thread control has to be part of the target vector today. Because remote-sim.c is missing implementations of the key methods, GDB cannot do even basic thread debugging with any of the builtin simulators, even if the simulator is executing a thread-supporting OS. That's not to say that it couldn't be done, but it would involve some decisions and some hacking. For instance, suppose you want to model a multiprocessor with a builtin sim, and have each processor appear to be a thread. That could be made to work. Now suppose you want to run a thread-supporting OS on your simulated multi-processor - should remote-sim.c report the processor "threads" or the OS threads. You may even want to switch back and forth! Whatever your choice, GDB must know all about how to start and stop each kind of thread, and how to display the list of threads. So as long as GDB supports basic thread debugging, it will have to have some knowledge of the OS implementing the threads. In any case, GDB does have all kinds of OS-specific knowledge for native OSes - what makes them so different? Indeed, native GDB has to have a whole separate set of code to access basic thread info in corefiles, because it can't make ptrace/ttrace calls then. Ideally the same generic embedded GDB should be able to debug all of these OSs. But instead of going through an intermediary debug agent, GDB (or an ICE under GDB's control) can examine and manipulate the targets memory and registers directly. Thus it seems wrong to put OS specific knowledge in the simulator's target vector. It should be at a higher level so that it can use the primitives provided by every target. Nobody is stopping you from using only primitives for your work. But you're saying that everybody should be made to use primitives, and that they must design their OS to accommodate that usage, whether or not it's reasonable for them. We're supposed to be adapting the debugger to meet the needs of the users, not forcing the users to conform to our preconceptions about how the debugger should be structured internally. Stan From ac131313@cygnus.com Tue Nov 30 17:26:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: memory verify Date: Tue, 30 Nov 1999 17:26:00 -0000 Message-id: <384478F8.B079BDC2@cygnus.com> References: <5memd74iem.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00377.html Content-length: 2527 "J.T. Conklin" wrote: > We need a target primitive for doing memory verifies. There are three > mechanisms that I can think of that can be used for this. Download a > chunk of memory and an address and have the target determine whether > they are the same; upload a chunk of memory at an address and have GDB > perform the comparison; and perform a CRC or strong hash function on > both the host and the target and compare the results. > > The second can be trivially implemented using the target vector's > memory read function. However verify performance can be improved > if the target supplies either a compare memory or checksum command. > > I propose the following new verify primitive: > > /* Verify that memory at GDB address MYADDR and target address > MEMADDR are identical. This can be done by downloading the > memory region to the target and having it do the comparison; > uploading the memory region to GDB and having it do the > comparision; using a checksum, cyclic redundency check, or > cryptographic hash function; etc. > > Return value, N, is one of the following: > > 0 - memory region is not identical. > > 1 - memory region is identical. */ > > int (*to_verify_memory) (CORE_ADDR memaddr, char *myaddr, int len); > > If the target cannot handle a memory region of that SIZE, the function > is responsible for breaking it up into chunks. Yes it's needed. It will allow me to eliminate a few more FIXME's :-). Several thoughts: I suspect that something like ``compare'' would convey a clearer meaning than ``verify''. Verify makes me think of a 20 line assembler program squeezed into a rom that verifies that memory is working :-) Rather than to_XXX_memory() handling broken transfers, I'd prefer it if the primitive returned the number of bytes matched by a single chunk. That keeps the primative simple. It would also be consistent with ->to_xfer_memory(). A value <=0 would indicate no match (exactly what zero means, given the spec for to_xfer_memory(), is ``left as an exercise for the reader'' ;-) A wrapper function could then provide the semantics you're looking for. What should the target do if it isn't able to provide a more efficient compare mechanism? My guess is leave the entry empty so that the higher level code is able to differentiate between an efficient target memory compare and a brutal memory read/compare. That would suggest target_XXX_memory_p() and target_XXX_memory(). enjoy, Andrew From jtc@redback.com Tue Nov 30 17:49:00 1999 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney <ac131313@cygnus.com> Cc: gdb@sourceware.cygnus.com Subject: Re: memory verify Date: Tue, 30 Nov 1999 17:49:00 -0000 Message-id: <5maenv4ehr.fsf@jtc.redbacknetworks.com> References: <5memd74iem.fsf@jtc.redbacknetworks.com> <384478F8.B079BDC2@cygnus.com> X-SW-Source: 1999-q4/msg00378.html Content-length: 1825 >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes: Andrew> I suspect that something like ``compare'' would convey a Andrew> clearer meaning than ``verify''. Verify makes me think of a Andrew> 20 line assembler program squeezed into a rom that verifies Andrew> that memory is working :-) Andrew> Rather than to_XXX_memory() handling broken transfers, I'd Andrew> prefer it if the primitive returned the number of bytes Andrew> matched by a single chunk. That keeps the primative simple. Andrew> It would also be consistent with to_xfer_memory(). A value Andrew> <=0 would indicate no match (exactly what zero means, given Andrew> the spec for to_xfer_memory(), is ``left as an exercise for Andrew> the reader'' ;-) A wrapper function could then provide the Andrew> semantics you're looking for. This is possible if either the host or the target are comparing the values, but when we're comparing checksums or CRCs all we know that some data somewhere is different. In that case, what value should be returned? Or are you suggesting the length is only interesting for successful compares of a chunk so we'll know where to start the next chunk? Andrew> What should the target do if it isn't able to provide a more Andrew> efficient compare mechanism? My guess is leave the entry Andrew> empty so that the higher level code is able to differentiate Andrew> between an efficient target memory compare and a brutal memory Andrew> read/compare. That would suggest target_XXX_memory_p() and Andrew> target_XXX_memory(). But is there a reason for higher level code to care how the compare is implemented? We could have target_XXX_memory check current_target-> to_XXX_memory --- if it's NULL, call that function otherwise a generic implementation would be used. --jtc -- J.T. Conklin RedBack Networks From shebs@cygnus.com Tue Nov 30 19:02:00 1999 From: Stan Shebs <shebs@cygnus.com> To: mainguen@gabin.frcl.bull.fr Cc: gdb@sourceware.cygnus.com Subject: Re: Gdb target for kdb Date: Tue, 30 Nov 1999 19:02:00 -0000 Message-id: <199912010302.TAA17555@andros.cygnus.com> References: <199911231620.RAA29254@gabin.frcl.bull.fr> X-SW-Source: 1999-q4/msg00379.html Content-length: 1086 Date: Tue, 23 Nov 1999 17:20:29 +0100 From: Bernard Mainguenaud <mainguen@gabin.frcl.bull.fr> We intend to use gdb to debug a running Linux kernel connected to another Linux box via an asynchronous line. For this purpose, we are considering developping a new gdb target that interfaces with kdb. Has anyone ever tried to develop such a kdb target before ? Not to my knowledge. As Jim Blandy, you could pretend it's like a ROM monitor and do a backend that way. However, it would be better to add a "GDB stub", which is a target-side implementation of the standard GDB protocol. Several of the Linux ports, such as for Sparc and Mips, already have stubs built in; look for gdb_* in the arch-dependent parts of the kernel. The x86 port does not include a stub, at least the last time I looked - supposedly Linus doesn't approve of debugging stubs, but I haven't heard him actually say that, and it may just be that no one has actually made the effort to get a stub in. If so, then this would be your chance to benefit other kernel developers... Stan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ST(i) and MMj 1999-11-30 10:20 ` none Jim Blandy @ 1999-12-01 0:21 ` Eli Zaretskii [not found] ` <npogca9tb8.fsf@zwingli.cygnus.com> 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 1999-12-01 0:21 UTC (permalink / raw) To: jimb; +Cc: gdb [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 13607 bytes --] (Note that I changed the subject: "none" seems inappropriate ;-) > If a symbol's address class (`aclass') is LOC_REGISTER and its value > is N, then GDB assumes the variable's value occupies register N. It > uses REGISTER_BYTE(N), REGISTER_RAW_SIZE(N), etc. to access that > symbol's value. We could arrange for REGISTER_RAW_SIZE and REGISTER_BYTE to perform the required mapping between %st(i) and %mmj using the current TOS. > We can't assign distinct register numbers to %st(0) and %mm0, for > reasons discussed previously: GDB can't cope with two distinct > register numbers referring to the same bits in the register file. During that discussion I did agree that these registers should not be treated as separate, but it seems we meant different things. What I meant was that it is a Bad Idea to maintain separate data for each one of these sets. In other words, if %st(3) corresponds to %mm0, it is wrong to have GDB maintain a separate data buffer where the contents of each one of these registers is held. The reason for this is that it would be very hard to teach GDB and the platform-specific code which data to use in each case, especially when the user changes the values in these registers and you need to pass the changed values to the debuggee. But I don't see why cannot GDB _think_ about %st(X) and %mmY as being separate registers while in reality they share the same data, if this sharing is concealed behind REGISTER_BYTE and REGISTER_RAW_SIZE (and possibly other functions/macros used to manipulate registers). What are the specific problems with this scheme? From ac131313@cygnus.com Wed Dec 01 00:39:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: memory verify Date: Wed, 01 Dec 1999 00:39:00 -0000 Message-id: <3844DE71.32797799@cygnus.com> References: <5memd74iem.fsf@jtc.redbacknetworks.com> <384478F8.B079BDC2@cygnus.com> <5maenv4ehr.fsf@jtc.redbacknetworks.com> <38449CE7.26320160@cygnus.com> <5maenvcfqd.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00385.html Content-length: 1542 "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes: > >> But is there a reason for higher level code to care how the compare > >> is implemented? We could have target_XXX_memory check > >> current_target-> to_XXX_memory --- if it's NULL, call that function > >> otherwise a generic implementation would be used. > > Andrew> Typically, yes. I can think of two cases: > Andrew> > Andrew> o a weak/broken CRC algorithm > Andrew> which the user doesn't like. > Andrew> > Andrew> o Internal operations such as > Andrew> program download that would exploit the CRC > Andrew> when available. (ex program load could run > Andrew> the crc before downloading each section. This > Andrew> could cleanup the compare sections command.). > > I don't think the existance of a to_XXX_memory() vector function is > enough of a hint for upper layers of GDB to decide whether to use it. > For example, changing generic_load() to call to_XXX_memory() on each > section to determine whether it is already loaded makes a lot of sense > with targets with CRC-like verification. Those that implement it with > a 'srecord verify'-like mechanism would lose (some ROM monitors have a > command where a srecord stream is compared with the contents of memory > instead of replacing the contents). But perhaps this is an argument > against using that kind of implementation. Thoughts? Bleuk :-) That suggests one requirement on that method is that it be significantly faster than a simple memory read :-) Andrew From ac131313@cygnus.com Wed Dec 01 00:57:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: "Brown, Rodney" <rodneybrown@pmsc.com> Cc: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com> Subject: Re: memory verify Date: Wed, 01 Dec 1999 00:57:00 -0000 Message-id: <3844E2C4.85B7A492@cygnus.com> References: <9150F3E779F0D211BD370008C733141C38AA12@aus-msg-02.au.pmsc.com> X-SW-Source: 1999-q4/msg00386.html Content-length: 1387 > "Brown, Rodney" wrote: > > Depending how capable the stubs are, you could look at using Andrew > Tridgewell's > rsync algorithms. I think that uses CRCs to locate differences in > files on > different boxes to generate a delta file to update the file on one. > This could allow the first difference idiom when run over large memory > areas, > without having to transmit the area over the wire. Yes, I've had that in the back of my mind. Several aspects of a typical embedded target make it less general then one would hope: o the typical target has a weak CRC (This suggests that perhaphs the check should have a requirement that it be ``strong''. How strong is an interesting question. o rcync's performance depends heavily on the stream nature of its remote connection. The typical target uses an RPC like mechanism. GDB's remote protocol is especially bad. The overhead of requesting CRC's could quickly mitigate any savings in avoiding downloads. o remote targets are small and dumb with all the the inteligence (?) and memory living in GDB. Having said that, an embedded implementation of rsync would make for an interesting performance boost when it came to re-loading memory. It would definitly be a challenge to add an rsync session (it would be a complex interaction than a simple exchange of packets) to GDB's remote protocol. enjoy, Andrew From ac131313@cygnus.com Wed Dec 01 01:55:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: David Golombek <daveg@maker.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Writing a new simulator Date: Wed, 01 Dec 1999 01:55:00 -0000 Message-id: <3844F02D.EEFFEE84@cygnus.com> References: <21vh6lj9mo.fsf@seattle143.maker.com> X-SW-Source: 1999-q4/msg00387.html Content-length: 2336 David Golombek wrote: > > I'm examining using the simulator code packaged with GDB for the basis > of a new simulator project. I haven't seen much discussion here about > the simulator packages, but haven't seen any other lists that might be > appropriate. If there is another list, please direct me towards it. > I've read through a fair bit of the existing code, and wanted to ask > some questions to make sure my assumptions are correct. > > This work is for a new processor, to which I've already ported the > Binutils, GDB, and Gas. This is for a 32bit processor with a lot of > special functional units, which are memory mapped. > > 1) It seems that using either the mips or the v850 code as an example > it the best bet, using the same igen framework that they use. T/F? Yes (along with the tic80 and d30v). The more recent simulators have tended to use igen and (more importantly) the sim/common framework. Another alternative would be to write your own simulator generator and just exploit the common framework. > 2) Reading the igen source, as well as the code in 'common', is the > only existing documentation on igen. T/F? Unfortunatly also true. The main igen documentation is in its header files where it describes the syntax of each file. > 3) Is there a good "ramp-up" methodology for writing a simulator, or > do I need to write very large parts of it before its useful at all? > IE, are there some pieces that I can implement first to get at least a > simulator that will run, if not do anything, so that I can do > piecewise implementation? Yes. Doing something like copying an existing sim directory (v850? tic80?) and then chopping it back to nothing is a good strategy. Just be ruthless. Simulators like the v850 were originally built using a gencode program and now many years later still show some of that in their internals. > 4) Are there any mail archives or any discussion saved anywhere of the > previous simulator implementations? Just to give me a heads up on > potential pit-falls, etc., that i may run into. To be honest, outside of direct discussions with people I work with, you're the first person to ask! There is an old PSIM mailing list / web site ( http://sourceware.cygnus.com/psim/ however that doesn't cover any of the the more recent sim/ developemnt. enjoy, Andrew From rok.papez@kiss.uni-lj.si Wed Dec 01 03:28:00 1999 From: Rok Papez <rok.papez@kiss.uni-lj.si> To: gdb@sourceware.cygnus.com, gnu-gdb-bug@moderators.isc.org Subject: Insight 19991116, gdbserver, fork() - always follows parent Date: Wed, 01 Dec 1999 03:28:00 -0000 Message-id: <99120112265800.00878@Strader.home> X-SW-Source: 1999-q4/msg00388.html Content-length: 1361 Hi! -> Problem description: ----------------- Even if I explicitly set follow-fork-mode to child, insight still follows a parent. I've succesfully compiled "insight 19991116" but I have encountered the following problems: ----------------- (gdb) s daemonize () at httpdial.c:105 105 rc=fork(); (gdb) show follow-fork-mode Debugger response to a program call of fork or vfork is "child". (gdb) n Program received signal SIGSTOP, Stopped (signal). 0x804926f in daemonize () at httpdial.c:105 105 rc=fork(); (gdb) show follow-fork-mode Debugger response to a program call of fork or vfork is "child". (gdb) n 106 if (-1==rc) { (gdb) p rc $1 = 11730 ----------------- -> Platforms: --------- Target is a Linux 2.2.13 (RH 6.0): - gdbserver from insight-19991116 - debugging via TCP Workstation is a Linux 2.2.13 (RH 6.0): - running insight GUI (problem tested with insight -nw) -> Questions: ---------- 1.) Is the insight 19991116 version same as gdb 19991116 ? 2.) Can insight and/or gdb finally work with LinuxThreads? What about gdbserver? Do new threads block when they get created ? 3.) How can I make gdb/insight/gdbserver follow a fork() && exec() ?? 4.) Is it possible to compile into the programme a breakpoint (so when it is run I could attach to it) - if yes - how to make it work with gdbserver. -- best regards, Rok Papez. From rodneybrown@pmsc.com Wed Dec 01 06:03:00 1999 From: "Brown, Rodney" <rodneybrown@pmsc.com> To: "'Andrew Cagney'" <ac131313@cygnus.com>, "Brown, Rodney" <rodneybrown@pmsc.com> Cc: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com> Subject: RE: memory verify Date: Wed, 01 Dec 1999 06:03:00 -0000 Message-id: <9150F3E779F0D211BD370008C733141C38AA13@aus-msg-02.au.pmsc.com> X-SW-Source: 1999-q4/msg00389.html Content-length: 2874 Title: RE: memory verify The loop unrolled CRC-32 used in the info-zip tools (with a bit of extra optimization) is 259 bytes i386 text space - but needs a 4*256 byte array. Assuming that ultimate speed in CRC calculation isn't needed in the stub then a nibble at a time varient - without loop unrolling should be possible in < 259 bytes with a 4*16 = 64 byte array. It should be possible to provide a CRC-32 in < 300 bytes (i386), if that is strong enough. Having just had a quick look at rsync, an MD4 checksum is being used - a cryptographic digest isn't it? If the rolling rsync checksum calculation is small enough & you replaced the MD4 checksum with one or two 32-bit CRC calculations you'd be able to do almost as well as with the MD4 checksum - but without the anti-tampering guarantees. Note that adding another 32-bit CRC polynomial should only cost another 64 bytes of array or so. -----Original Message----- From: Andrew Cagney [ mailto:ac131313@cygnus.com ] Sent: Wednesday, 1 December 1999 19:57 To: Brown, Rodney Cc: 'gdb@sourceware.cygnus.com' Subject: Re: memory verify > "Brown, Rodney" wrote: > > Depending how capable the stubs are, you could look at using Andrew > Tridgewell's > rsync algorithms. I think that uses CRCs to locate differences in > files on > different boxes to generate a delta file to update the file on one. > This could allow the first difference idiom when run over large memory > areas, > without having to transmit the area over the wire. Yes, I've had that in the back of my mind. Several aspects of a typical embedded target make it less general then one would hope:        o      the typical target has a weak CRC               (This suggests that perhaphs the check should               have a requirement that it be ``strong''.               How strong is an interesting question.        o      rcync's performance depends heavily on the               stream nature of its remote connection.               The typical target uses an RPC like mechanism.               GDB's remote protocol is especially bad. The               overhead of requesting CRC's could quickly               mitigate any savings in avoiding downloads.        o      remote targets are small and dumb with all the               the inteligence (?) and memory living in GDB. Having said that, an embedded implementation of rsync would make for an interesting performance boost when it came to re-loading memory. It would definitly be a challenge to add an rsync session (it would be a complex interaction than a simple exchange of packets) to GDB's remote protocol.        enjoy,               Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <npogca9tb8.fsf@zwingli.cygnus.com>]
[parent not found: <3845AB0E.3795D99E@ozemail.com.au>]
* Re: Standard GDB Remote Protocol [not found] ` <3845AB0E.3795D99E@ozemail.com.au> @ 1999-12-01 15:43 ` Quality Quorum 1999-12-01 15:53 ` Stan Shebs [not found] ` <5md7sql00o.fsf@jtc.redbacknetworks.com> 2 siblings, 0 replies; 8+ messages in thread From: Quality Quorum @ 1999-12-01 15:43 UTC (permalink / raw) To: Steven Johnson; +Cc: gdb On Thu, 2 Dec 1999, Steven Johnson wrote: > I am about to write a GDB Remote Stub, and I want to use the standard > GDB Remote protocol for this. > > Can anyone point me at the Protocol specification for this? Or doesn't > it exist? > > Ive looked everywhere I can think of and can find nothing documented > about it, except references to the fact GDB has this standard Protocol. > > I Know i'll get the answer "Use the Source". But that is hardly > appropriate for a Protocol. There are far more subtleties to Protocol > Design and Implementation than can usually be gleaned from anyone's > source code. > > If it doesn't exist, does anyone have any objections to a complete, > formal, Protocol specification for the GDB Remote Protocol being > created. (Note: here Im putting up my hand. If I have to reverse > engineer it from the code, Im going to document it for my benefit > anyway.) > > If it does exist, is it up-to-date? Look at http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html#SEC115 It seems quite uptodate. > > If I need to create one, what format should I create it in? (i.e., > preferred document type). > > Steven Johnson > Managing Director > Neurizon Pty Ltd > Thanks, Aleksey ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Standard GDB Remote Protocol [not found] ` <3845AB0E.3795D99E@ozemail.com.au> 1999-12-01 15:43 ` Standard GDB Remote Protocol Quality Quorum @ 1999-12-01 15:53 ` Stan Shebs [not found] ` <5md7sql00o.fsf@jtc.redbacknetworks.com> 2 siblings, 0 replies; 8+ messages in thread From: Stan Shebs @ 1999-12-01 15:53 UTC (permalink / raw) To: sbjohnson; +Cc: gdb Date: Thu, 02 Dec 1999 09:11:10 +1000 From: Steven Johnson <sbjohnson@ozemail.com.au> Can anyone point me at the Protocol specification for this? Or doesn't it exist? Ive looked everywhere I can think of and can find nothing documented about it, except references to the fact GDB has this standard Protocol. As other people have pointed out, the complete spec is now part of the main GDB manual. The 4.18 manual and earlier had a partial and out-of-date description in section 13.4.14 "Communication protocol". We've updated and expanded this section, and the description in the manual is now the official specification for the protocol. So feel free to rely on the manual, and if you find the description is lacking or erroneous, please help us to correct it (or GDB); your effort will be much appreciated by everybody. Stan From davidwilliams@ozemail.com.au Wed Dec 01 16:23:00 1999 From: David Williams <davidwilliams@ozemail.com.au> To: "'gdb mail list'" <gdb@sourceware.cygnus.com> Subject: remote debug of 68EZ328 Date: Wed, 01 Dec 1999 16:23:00 -0000 Message-id: <01BF3CB7.62CF55A0.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00411.html Content-length: 1311 Hi All, I am still trying to ramp up on required knowledge to tackle this... 1. As far as I can tell, the remote protocol specifies communications between a stub on the target system and GDB on host system. I assume that there is some 68K specific code as part of GDB that communicates to stub on target system - I am a little cloudy on this and would appreciate some clarification. 2. Looking through the procotol & source for 68K-stub leads me to believe that the 68K stub (and possibly all stubs) do not support hardware breakpoints - they work by assuming code is running is RAM and op-code can be substituted for trap instructions. Is this correct? If so then I cannot use the remote protocol and a stub to support hardware breakpoints. What other method is best. (I have received some responses to previous queries on this subject but I still dont get it!) 3. Some people have mentioned insight to me. The suggestion is the Insight may have slightly different (and possible later) sources for GDB component. Is this true? I am interested in using a GUI with GDB and this sounds good. My specific problems are that I am currently using win95 as my development platform (yes I know) and dont know how this will affect development of changes required to GDB (Insight). TIA David Williams From shebs@cygnus.com Wed Dec 01 17:11:00 1999 From: Stan Shebs <shebs@cygnus.com> To: davidwilliams@ozemail.com.au Cc: gdb@sourceware.cygnus.com Subject: Re: remote debug of 68EZ328 Date: Wed, 01 Dec 1999 17:11:00 -0000 Message-id: <199912020111.RAA01159@andros.cygnus.com> References: <01BF3CB7.62CF55A0.davidwilliams@ozemail.com.au> X-SW-Source: 1999-q4/msg00412.html Content-length: 3890 From: David Williams <davidwilliams@ozemail.com.au> Date: Thu, 2 Dec 1999 11:21:31 +1100 I am still trying to ramp up on required knowledge to tackle this... 1. As far as I can tell, the remote protocol specifies communications between a stub on the target system and GDB on host system. I assume that there is some 68K specific code as part of GDB that communicates to stub on target system - I am a little cloudy on this and would appreciate some clarification. Yes, GDB has m68k-specific code that describes the architecture in a somewhat abstract way, and only in as much detail as the debugger needs. So for instance, there are bits saying that d0 is a 32-bit register, a6 is the frame pointer, fp0 contains floats, etc. There are also procedures to do things like decoding frames. All of this code is common to all m68k systems, whether they're Apollos, Sun-3s, Palms, whatever. The remote protocol and its implementation are very generic. The protocol is just a set of commands, like "$g#67", which says to deliver all the registers. The size of the response is very different from one system to another, but GDB just hopes for the best :-) and dumps the blob of data into the array of registers. Once GDB has acquired some register and memory data via the generic protocol, it puts its m68k-specific code to work analyzing it, eventually resulting in a reconstruction of your program's state. So the purpose of your stub is simply to report program state and to obey the commands (packets) sent to it by GDB. Since GDB has no other means to contact the target system except the stub, it will pretty much believe what your stub tells it. This suggests interesting tricks that you can do - for instance, you could notice that a memory write seems to be the depositing of a breakpoint instruction, and do something else, like set a hardware breakpoint. As long as you're telling GDB believable things, it will go along. 2. Looking through the procotol & source for 68K-stub leads me to believe that the 68K stub (and possibly all stubs) do not support hardware breakpoints - they work by assuming code is running is RAM and op-code can be substituted for trap instructions. Is this correct? If so then I cannot use the remote protocol and a stub to support hardware breakpoints. What other method is best. (I have received some responses to previous queries on this subject but I still dont get it!) We've recently defined a 'Z' packet that is for the purpose of setting hardware breakpoints. The generic m68k stub in the sources doesn't use it, because any such code would be very specific to particular systems. As you may have noticed, the stub file is public domain, not even GPLed, because we want everybody to modify stubs so they'll fit properly into the target system. As long as you conform to the established protocol as defined in the manual, you can do whatever you want. 3. Some people have mentioned insight to me. The suggestion is the Insight may have slightly different (and possible later) sources for GDB component. Is this true? I am interested in using a GUI with GDB and this sounds good. My specific problems are that I am currently using win95 as my development platform (yes I know) and dont know how this will affect development of changes required to GDB (Insight). Since you're already used to crashes, you won't be any worse off than you are now... :-) Insight is just a tcl GUI extension to basic GDB. The snapshot sources on sourceware are synced with the basic GDB sources available at the same place, so you can use either as you prefer. Building everything from scratch using cygwin on W95 usually takes so long that something crashes before it finishes, but if you reboot and continue building, you can eventually get to a working GDB. Stan From sbjohnson@ozemail.com.au Wed Dec 01 20:22:00 1999 From: Steven Johnson <sbjohnson@ozemail.com.au> To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Wed, 01 Dec 1999 20:22:00 -0000 Message-id: <3845F45A.38EA29CF@ozemail.com.au> 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> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00413.html Content-length: 11909 "J.T. Conklin" wrote: > > Since you're putting up your hand, would you be willing to review the > protocol spec and point out areas that are ambiguous, confusing, need > revising, etc? > Following is a Hopefully Constructive Critique, of the GDB Remote Protocol. It is based on my First Read of the current online version of protocol specification at: http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html In my Critique, I am not posing real questions when I discuss subjects. What I am doing is hi-lighting areas where I have questions in my own mind, where I find the description of the protocol lacking. The answers will probably be present in the current implemented code and stubs, and I have not yet looked for those answers. Nor do I wish to, until my initial analysis of the Protocol is complete. I do not wish to taint my understanding of the written words of the protocol with Black Knowledge gleaned from the source. Further my critique is not a criticism of the hard work that people have already done to get the documentation/GDB/protocol to this state. Further it is obvious from my first read of the protocol is that it has undergone extensive evolution, and I have taken this into consideration. Any comments I make on ways to fix things are simply my attempt at understanding the problem. They do not represent a request or proposal to change anything in the protocol, they are presented as part of the thought process I underwent when analysing the protocol. They also indicate areas where I have concerns with my understanding of the protocol as documented. Packet Structure: Simple structure, obviously originally designed to be able to be driven manually from a TTY. (Hence it's ASCII nature.) However, the protocol has evolved quite significantly and I doubt it could still be used very efficiently from a TTY. That said, it still demarks frames effectively. Sequence Numbers: Definition of Sequence ID's needs work. Are they necessary? Are they deprecated? What purpose do they currently serve within GDB? One would imagine that they are used to allow GDB to handle retransmits from a remote system. Reading between the lines, this is done to allow error recovery when a transmission from target to host fails. Possible sequence being: <- $packet-data#checksum -> + -> $sequence-id:packet-data#checksum (checksum fails or receive timeout halfway through packet). <- -sequence-id -> $sequence-id:packet-data#checksum <- +sequence-id When do the sequence-id's increment? Presumably on the successful receipt of the +sequence-id acknowledgement. If they increment on the successful acknowledgement, what happens if the acknowledgement is in error? For example a framing error on the '+'. The target would never see the successful acknowledgement and would not increment it's sequence number. So what if it doesn't? The +/- Ack/Nak mechanism should be amply sufficient to allow retransmits of missed responses. I can see little practical benefit in a sequence-id in the responses, as it is currently documented. This is supported buy the comment within the document: "Beyond that its meaning is poorly defined. GDB is not known to output sequence-ids". This tends to indicate that the mechanism has fallen out of use, Probably because it doesn't actually achieve anything. If this is the case, it could be deprecated. However, I would advocate not deprecating it from the protocol, because If they were sent by GDB a current hole I believe is in the protocol could be plugged. (I will discuss this hole later in this critique.) Ack/Nak Mechanism: Simple Ack/Nak Mechanism, using + and - Respectively. Also reflects the simple ASCII basis of the protocol. My main concern with this system is there is no documentation of timing. Usually Ack/Nak must be received within a certain time frame, otherwise a Nak is assumed and a retransmit proceeds. This is necessary, because it is possible for the Ack/Nak character to be lost (however unlikely) on the line due to a data error. I think there should be a general timing basis to the entire protocol to tie up some potential communications/implementation problems. The 2 primary timing constraints I see that are missing are: Inter character times during a message transmission, and Ack/Nak response times. If a message is only half received, the receiver has no ability without a timeout mechanism of generating a NAK signalling failed receipt. If this occurs, and there is no timeout on ACK/NAK reception, the entire comms stream could Hang. Transmitter is Hung waiting for an ACK/NAK and the Receiver is Hung waiting for the rest of the message. I would propose that something needs to be defined along the lines of: Once the $ character for the start of a packet is transmitted, each subsequent byte must be received within "n" byte transmission times. (This would allow for varying comms line speeds). Or alternately a global timeout on the whole message could be define one "$" (start sentinel) is sent, the complete message must be received within "X" time. I personally favour the inter character time as opposed to complete message time as it will work with any size message, however the complete message time restrict the maximum size of any one message (to how many bytes can be sent at the maximum rate for the period). These tiemouts do not need to be very tight, as they are merely for complete failure recovery and a little delay there does not hurt much. One possible timeout that would be easy to work with could be: Timeout occurs 1 second after the last received byte. For ACK/NAK I propose that something needs to be defined along the lines: ACK/NAK must be received within X Seconds from transmission of the end of the message, otherwise a NAK must be assumed. There is no documentation of the recovery procedure, Does GDB retransmit if its message is responded to with a NAK? If not, what does it do? How is the target supposed to identify and handle retransmits from GDB. What happens if something other than + or - is received when ACK/NAK is expected. (For example $). Identified Protocol Hole: Lets look at the following abstract scenario (Text in brackets are supporting comments): <- $packet-data#checksum (Run Target Command) -> + (Response is lost due to a line error) (Target runs for a very short period of time and then breaks). -> $sequence-id:packet-data#checksum (Break Response - GDB takes as a NAK, expecting a +, got a $). <- $packet-data#checksum (GDB retransmits it's Run Target Command, target restarts) -> + (Response received OK by GDB). (Target again starts running.) In this scenario, it is shown that with the currently documented mechanisms, it is possible for transmission errors to occur that interfere with debugging. There was no mechanism for the target to identify that GDB was re-transmitting and subsequently executed the same operation twice. When GDB really only wanted to execute the command once. Its this sort of scenario that I imagine the sequence id's were created for. If GDB sent Sequence ID's then the scenario would be much different: <- $ sequence-id:packet-data#checksum (Run Target Command) -> + (Response is lost due to a line error) (Target runs for a very short period of time and then breaks). -> $sequence-id:packet-data#checksum (Break Response - GDB takes as a NAK, expecting a +, got a $). <- $ sequence-id:packet-data#checksum (GDB retransmits it's Run Target Command, with the same sequence -id as in the original command) (Target identifies the sequence-id as a retransmit.) (Instead of performing the operation again, it simply re-responds with the results obtained from the last command) -> + (Response received OK by GDB). -> $sequence-id:packet-data#checksum (Break Response - GDB processes as expected.) (GDB then increments its sequence-id in preparation for the next command.) As an extra integrity check, the response sequence-id should be identical to the request sequence-id. This would allow GDB to verify that the response it is processing is properly paired with it's request. Further, the target shouldn't require either ACK nor NAK. It should process them properly if received, but otherwise process the received packet, even if ACK/NAK was expected. If this is the intent of sequence-id and it has fallen into disuse, then to allow it's re-introduction at a later date, it could be documented that if GDB sends a sequence-id, then the retransmit processing I've documented here operates, otherwise the currently defined behaviour operates, and that sequence-id is only sent by the target in responses where they are present in the original GDB message. This would allow GDB to probe if the target supports secure and recoverable message delivery or not. Run Length Encoding: Is run length encoding supported in all packets, or just some packets? (For example, not binary packets) Why not allow lengths greater than 126? Or does this mean lengths greater than 97 (as in 126-29) If binary packets with 8 bit data can be sent, why not allow RLE to use length also greater than 97. If the length maximum is really 126, then this yields the character 0x9B which is 8 bits, wouldn't the maximum length in this case be 226. Or is this a misprint? Why are there 2 methods of RLE? Is it important for a Remote Target to understand and process both, or is the "cisco encoding" a proprietary extension of the GDB Remote protocol, and not part of the standard implementation. The documentation of "cisco encoding" is confusing and seems to conflict with standard RLE encoding. They appear to be mutually exclusive. If they are both part of the protocol, how are they distinguished when used? Deprecated Messages: Should an implementation of the protocol implement the deprecated messages or not? What is the significance of the deprecated messages to the current implementation? Character Escaping: The mechanism of Escaping the characters is not defined. Further it is only defined as used by write mem binary. Wouldn't it be useful for future expansion of the protocol to define Character Escaping as a global feature of the protocol, so that if any control characters were required to be sent, they could be escaped in a consistent manner across all messages. Also, wouldn't the full list of escape characters be $,#,+,-,*,0x7d. Otherwise, + & - might be processed inadvertently as ACK or NAK. If this can't happen, then why must they be avoided in RLE? If they are escaped across all messages, then that means they could be used in RLE and not treated specially. 8/7 Bit protocol. With the documentation of RAW Binary transfers, the protocol moves from being a strictly 7 bit affair into being a 8 bit capable protocol. If this is so, then shouldn't all the restrictions that are placed from the 7 bit protocol days be lifted to take advantage of the capabilities of an 8 bit message stream. (RLE limitations, for example). Would anyone seriously be using a computer that had a 7 bit limitation anymore anyway? (At least a computer that would run GDB with remote debugging). Thoughts on consistency and future growth: Apply RLE as a feature of All messages. (Including binary messages, as these can probably benefit significantly from it). Apply the Binary Escaping mechanism as a feature of the packet that is performed on all messages prior to transmission and immediately after reception. Define an exhaustive set of "Characters to be escaped". Introduce message timing constraints. Properly define sequence-id and allow it to be used from GDB to make communications secure and reliable. Steven Johnson Managing Director Neurizon Pty Ltd From jtc@redback.com Thu Dec 02 00:50:00 1999 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: using '-x -' to read gdb script from stdin Date: Thu, 02 Dec 1999 00:50:00 -0000 Message-id: <5miu2hhgkx.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00414.html Content-length: 991 I updated one of our year old GDB executables a week or so ago, and was notified that one of the scripts used by SQA failed to work. I tracked it down to the following bit of code that was ifdef'd out earlier this year. From main.c: /* NOTE: I am commenting this out, because it is not clear where this feature is used. It is very old and undocumented. ezannoni: 1999-05-04 */ #if 0 if (cmdarg[i][0] == '-' && cmdarg[i][1] == '\0') read_command_file (stdin); else #endif The script invoked gdb like this: echo list "*$addr" | $gdb -batch -x - $file | head -1 [ I know, I should be using addr2line. But this script was written before addr2line existed. ] Since all of our systems support /dev/stdin, I patched up our script accordingly. But I wonder whether support for - should be reenabled. Is there any reason why not? --jtc -- J.T. Conklin RedBack Networks From eliz@gnu.org Thu Dec 02 06:14:00 1999 From: Eli Zaretskii <eliz@gnu.org> To: gdb@sourceware.cygnus.com Cc: Andrew Cagney <ac131313@cygnus.com>, DJ Delorie <dj@delorie.com> Subject: Re: -Wmissing-prototypes ... Date: Thu, 02 Dec 1999 06:14:00 -0000 Message-id: <199912021414.JAA16068@mescaline.gnu.org> References: <37E5E508.D56E054C@cygnus.com> <37CB6DBE.2083662F@cygnus.com> X-SW-Source: 1999-q4/msg00415.html Content-length: 8681 > My current list is: > > --enable-build-warnings=-Werror\ > ,-Wimplicit\ > ,-Wreturn-type\ > ,-Wcomment\ > ,-Wtrigraphs\ > ,-Wformat\ > ,-Wparentheses\ > ,-Wpointer-arith\ > ,-Wmissing-prototypes\ > ,-Woverloaded-virtual\ Here are the patches for go32-nat.c to allow it to compile with all kinds of -Wfoo switches (I added switches beyond those mentioned above). While working on this, I found out that defs.h redeclares several library functions, like getenv, fclose and atof, because symbols like GETENV_PROVIDED etc. aren't defined anywhere; this causes GCC to complain (under the full list of warning options). What header should define those for a particular host? --- gdb/go32-nat.~17 Wed Dec 1 20:02:36 1999 +++ gdb/go32-nat.c Wed Dec 1 20:57:06 1999 @@ -29,6 +29,7 @@ #include "gdbcore.h" #include "command.h" #include "floatformat.h" +#include "language.h" #include <stdio.h> /* required for __DJGPP_MINOR__ */ #include <stdlib.h> @@ -164,42 +165,47 @@ #define SOME_PID 42 static int prog_has_started = 0; -static void print_387_status (unsigned short status, struct env387 *ep); -static void go32_open (char *name, int from_tty); -static void go32_close (int quitting); -static void go32_attach (char *args, int from_tty); -static void go32_detach (char *args, int from_tty); -static void go32_resume (int pid, int step, enum target_signal siggnal); -static int go32_wait (int pid, struct target_waitstatus *status); -static void go32_fetch_registers (int regno); -static void store_register (int regno); -static void go32_store_registers (int regno); +static void print_387_status (unsigned, struct env387 *); +static void go32_open (char *, int); +static void go32_close (int); +static void go32_attach (char *, int); +static void go32_detach (char *, int); +static void go32_resume (int, int, enum target_signal); +static int go32_wait (int, struct target_waitstatus *); +static void go32_fetch_registers (int); +static void store_register (int); +static void go32_store_registers (int); static void go32_prepare_to_store (void); -static int go32_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, - int write, struct target_ops *target); -static void go32_files_info (struct target_ops *target); +static int go32_xfer_memory (CORE_ADDR, char *, int, + int, struct target_ops *); +static void go32_files_info (struct target_ops *); static void go32_stop (void); static void go32_kill_inferior (void); -static void go32_create_inferior (char *exec_file, char *args, char **env); +static void go32_create_inferior (char *, char *, char **); static void cleanup_dregs (void); static void go32_mourn_inferior (void); static int go32_can_run (void); static void ignore (void); -static void ignore2 (char *a, int b); -static int go32_insert_aligned_watchpoint (CORE_ADDR waddr, CORE_ADDR addr, - int len, int rw); -static int go32_remove_aligned_watchpoint (CORE_ADDR waddr, CORE_ADDR addr, - int len, int rw); -static int go32_handle_nonaligned_watchpoint (wp_op what, CORE_ADDR waddr, - CORE_ADDR addr, int len, int rw); +static int go32_insert_aligned_watchpoint (CORE_ADDR, CORE_ADDR, int, int); +static int go32_remove_aligned_watchpoint (CORE_ADDR, CORE_ADDR, int, int); +static int go32_handle_nonaligned_watchpoint (wp_op, CORE_ADDR, CORE_ADDR, + int, int); static struct target_ops go32_ops; static void go32_terminal_init (void); static void go32_terminal_inferior (void); static void go32_terminal_ours (void); +int go32_insert_watchpoint (int, CORE_ADDR, int, int); +int go32_remove_watchpoint (int, CORE_ADDR, int, int); +int go32_region_ok_for_watchpoint (CORE_ADDR, int); +CORE_ADDR go32_stopped_by_watchpoint (int, int); +int go32_insert_hw_breakpoint (CORE_ADDR, CORE_ADDR); +int go32_remove_hw_breakpoint (CORE_ADDR, CORE_ADDR); + + static void -print_387_status (unsigned short status, struct env387 *ep) +print_387_status (unsigned status, struct env387 *ep) { int i; int bothstatus; @@ -221,7 +227,7 @@ print_387_status_word (ep->status); } - print_387_control_word (ep->control & 0xffff); + print_387_control_word ((unsigned)ep->control & 0xffff); /* Other platforms say "last exception", but that's not true: the FPU stores the last non-control instruction there. */ printf_unfiltered ("last FP instruction: "); @@ -229,7 +235,8 @@ are not stored by the FPU (since these bits are the same for all floating-point instructions). */ printf_unfiltered ("opcode %s; ", - local_hex_string (ep->opcode ? (ep->opcode|0xd800) : 0)); + local_hex_string (ep->opcode + ? (unsigned)(ep->opcode|0xd800) : 0)); printf_unfiltered ("pc %s:", local_hex_string (ep->code_seg)); printf_unfiltered ("%s; ", local_hex_string (ep->eip)); printf_unfiltered ("operand %s", local_hex_string (ep->operand_seg)); @@ -244,7 +251,7 @@ order, beginning with ST(0). Since we need to print them in their physical order, we have to remap them. */ int regno = fpreg - top; - long double val; + long double ldval; if (regno < 0) regno += 8; @@ -272,9 +279,9 @@ printf_unfiltered ("%02x", ep->regs[regno][i]); REGISTER_CONVERT_TO_VIRTUAL (FP0_REGNUM+regno, builtin_type_long_double, - &ep->regs[regno], &val); + &ep->regs[regno], &ldval); - printf_unfiltered (" %.19LG\n", val); + printf_unfiltered (" %.19LG\n", ldval); } } @@ -381,7 +388,7 @@ TARGET_SIGNAL_QUIT, 0x7a, TARGET_SIGNAL_ALRM, 0x78, /* triggers SIGTIMR */ TARGET_SIGNAL_PROF, 0x78, - -1, -1 + (enum target_signal)-1, -1 }; static void @@ -420,7 +427,8 @@ if (siggnal != TARGET_SIGNAL_0 && siggnal != TARGET_SIGNAL_TRAP) { - for (i = 0, resume_signal = -1; excepn_map[i].gdb_sig != -1; i++) + for (i = 0, resume_signal = -1; + excepn_map[i].gdb_sig != (enum target_signal)-1; i++) if (excepn_map[i].gdb_sig == siggnal) { resume_signal = excepn_map[i].djgpp_excepno; @@ -439,7 +447,7 @@ { int i; unsigned char saved_opcode; - unsigned long INT3_addr; + unsigned long INT3_addr = 0L; int stepping_over_INT = 0; a_tss.tss_eflags &= 0xfeff; /* reset the single-step flag (TF) */ @@ -594,14 +602,14 @@ static void go32_store_registers (int regno) { - int r; + unsigned r; if (regno >= 0) store_register (regno); else { for (r = 0; r < sizeof (regno_mapping) / sizeof (regno_mapping[0]); r++) - store_register (r); + store_register ((int)r); } } @@ -611,12 +619,12 @@ } static int -go32_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write, +go32_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int to_write, struct target_ops *target) { - if (write) + if (to_write) { - if (write_child (memaddr, myaddr, len)) + if (write_child (memaddr, myaddr, (unsigned)len)) { return 0; } @@ -627,7 +635,7 @@ } else { - if (read_child (memaddr, myaddr, len)) + if (read_child (memaddr, myaddr, (unsigned)len)) { return 0; } @@ -820,12 +828,13 @@ #define SHOW_DR(text,len) \ do { \ if (!getenv ("GDB_SHOW_DR")) break; \ - fprintf(stderr,"%08x %08x ",edi.dr[7],edi.dr[6]); \ - fprintf(stderr,"%08x %d %08x %d ", \ + fprintf(stderr,"%08lx %08lx ",edi.dr[7],edi.dr[6]); \ + fprintf(stderr,"%08lx %d %08lx %d ", \ edi.dr[0],dr_ref_count[0],edi.dr[1],dr_ref_count[1]); \ - fprintf(stderr,"%08x %d %08x %d ", \ + fprintf(stderr,"%08lx %d %08lx %d ", \ edi.dr[2],dr_ref_count[2],edi.dr[3],dr_ref_count[3]); \ - fprintf(stderr,(len)?"(%s:%d)\n":"(%s)\n",#text,len); \ + if (len) fprintf(stderr,"(%s:%d)\n",#text,len); \ + else fprintf(stderr,"(%s)\n",#text); \ } while (0) #else #define SHOW_DR(text,len) do {} while (0) @@ -861,7 +870,7 @@ int len, int rw) { int i; - int read_write_bits, len_bits; + unsigned read_write_bits, len_bits; /* Values of rw: 0 - write, 1 - read, 2 - access (read and write). However, x86 doesn't support read-only data breakpoints. */ @@ -992,7 +1001,7 @@ int len, int rw) { int i; - int read_write_bits, len_bits; + unsigned read_write_bits, len_bits; /* Values of rw: 0 - write, 1 - read, 2 - access (read and write). However, x86 doesn't support read-only data breakpoints. */ @@ -1105,9 +1114,6 @@ go32_insert_hw_breakpoint (CORE_ADDR addr, CORE_ADDR shadow) { int i; - int read_write_bits, len_bits; - int free_debug_register; - int register_number; /* Look for an occupied debug register with the same address and the same RW and LEN definitions. If we find one, we can use it for From gatliff@haulpak.com Thu Dec 02 06:43:00 1999 From: William Gatliff <gatliff@haulpak.com> To: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Thu, 02 Dec 1999 06:43:00 -0000 Message-id: <384685A7.15184EB1@haulpak.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> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> X-SW-Source: 1999-q4/msg00416.html Content-length: 5911 Steven Johnson wrote: > Packet Structure: > > Simple structure, obviously originally designed to be able to be driven > manually from a TTY. (Hence it's ASCII nature.) However, the protocol has > evolved quite significantly and I doubt it could still be used very > efficiently from a TTY. True, but it can still be *monitored* quite effectively with a TTY, and simple things like a ? query are still possible. If I'm using a TTY then I'm desperate anyway, so I'm willing to put up with a little pain. Go to a non-ASCII protocol, however, and the TTY option is right out altogether, no matter how desperate I am! If efficiency/throughput is a problem, then go to ethernet. At 10/100Mbps, even the overhead of ASCII isn't a problem for most targets I can think of. > I think there should be a general timing basis to the entire protocol to > tie up some potential communications/implementation problems. The RSP's lack of timing requirements is an asset, as far as I'm concerned. See below. > If a message is only half received, the receiver has no ability without a > timeout mechanism of generating a NAK signalling failed receipt. If this > occurs, and there is no timeout on ACK/NAK reception, the entire comms > stream could Hang. Transmitter is Hung waiting for an ACK/NAK and the > Receiver is Hung waiting for the rest of the message. This is something that a stub can handle itself, as a self-protection measure, without changing the RSP. A debugging stub running on production hardware would probably need to do this anyway, while a lab/development system could tolerate a hang (concerns with rotating machinery, etc. notwithstanding). So, I don't see any reason to create requirements, because they're likely to be so target-specific that you'll never get good agreement on what they should be, and therefore there will not be any uniform implementations. In my opinion, a debugging stub is the responsible party for the safety of a debugging target, because it alone can decide what to do if it thinks that gdb has "gone away" unexpectedly (line noise, PC/protocol hang, etc.). When this is done, nobody cares if gdb hangs, because it doesn't necessarily cause problems for the target. From that perspective, it is clear to me that a debugging stub will have to do whatever it needs to do to protect itself and the target, regardless of what the RSP says. So the mission to beef up the RSP in the way you suggest seems counterproductive. In the best case, you'll drive the need for gdb enhancements that won't benefit most people (i.e. timing requirements that are so loose that targets cannot depend on them); in the worst case, you'll create gdb behaviors that are incompatible with certain types of targets (i.e. timing requirements that are so tight that targets and hosts can't implement them). > I would propose that something needs to be defined along the lines of: > > Once the $ character for the start of a packet is transmitted, each > subsequent byte must be received within "n" byte transmission times. > (This would allow for varying comms line speeds). Or alternately a global > timeout on the whole message could be define one "$" (start sentinel) is > sent, the complete message must be received within "X" time. I personally > favour the inter character time as opposed to complete message time as it > will work with any size message, however the complete message time > restrict the maximum size of any one message (to how many bytes can be > sent at the maximum rate for the period). These tiemouts do not need to > be very tight, as they are merely for complete failure recovery and a > little delay there does not hurt much. > > One possible timeout that would be easy to work with could be: Timeout > occurs 1 second after the last received byte. > > For ACK/NAK I propose that something needs to be defined along the lines: > ACK/NAK must be received within X Seconds from transmission of the end of > the message, otherwise a NAK must be assumed. Good suggestions, but I would prefer that these be general stub design guidelines that aren't enforced by gdb. Let gdb be as flexible as possible, so that it will work with super-smart stubs that do all the timing stuff properly, as well as stubs that are minimally written. Gdb is supposed to be a debugging aid; I would prefer that all the protocol stuff not get in the way of its fundamental mission. Also, how do you measure byte times on most debugging hosts, particularly at 115K (my bit rate of choice) and higher? Such a specification sounds easy, but an implementation isn't likely to be portable. And finally, consider the case where an M command is really writing to flash, and the debugging target gets busy erasing flash sectors (which can take longer than a second in some cases)? If gdb retries, things may get confusing. > There is no documentation of the recovery procedure, Does GDB retransmit > if its message is responded to with a NAK? If not, what does it do? How > is the target supposed to identify and handle retransmits from GDB. > What happens if something other than + or - is received when ACK/NAK is > expected. (For example $). From my own experience, remote.c is kinda fragile where stuff like this is concerned. I had been intending to look into this myself next year, but by then someone else will have certainly beaten me to it. I think some improvements have already been made. > Character Escaping: The mechanism of Escaping the characters is not > defined. Further it is only defined as used by write mem binary. That's because this is the only place where it is needed, AFAIK. And, since X is optional (and support for it is detected automatically by gdb), that means that I don't have to implement it if I don't want to. Bonus for super-minimal stubs. b.g. -- William A. Gatliff Senior Design Engineer Komatsu Mining Systems To teach is to learn. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <5md7sql00o.fsf@jtc.redbacknetworks.com>]
[parent not found: <3845F45A.38EA29CF@ozemail.com.au>]
[parent not found: <384685A7.15184EB1@haulpak.com>]
[parent not found: <38470CC1.1B0E5C27@ozemail.com.au>]
* Re: Standard GDB Remote Protocol [not found] ` <38470CC1.1B0E5C27@ozemail.com.au> @ 1999-12-03 5:41 ` Bill Gatliff 0 siblings, 0 replies; 8+ messages in thread From: Bill Gatliff @ 1999-12-03 5:41 UTC (permalink / raw) To: gdb Steven: [snip snip] Sounds like we agree more than we disagree. *whew*! :^) > Yes, here's the issue. The document is completely lacking in stub > implementation guidelines. IMHO, there needs to be a section of the > protocol (or comments throughout it) that give this sort of information > and advice to implementers of stubs. Here's where a good reference stub library might be of use. (As instructive as they are, I'm not sure the example stubs qualify in this department). I'm working on such a beast, mostly because I routinely work with more than one type of embedded processor. I have it done for the SH-2 (although I'm still adding some exception handling), someone is helping with an ARM port, and Dave Williams is looking at for a 68k port. If anyone else was interested in the code, I would be happy to see it placed on a Cygnus web/cvs site somewhere--- at the moment, however, I don't have the resources or time to set something up myself. > Again I agree with this. I was making the observation that Character > Escaping is likely to become more prevalent as the protocol evolves. To > define character escaping around one message could create a situation > where different messages that require it implement different mechanisms. Escaping seems to be most needed in messages with binary content, of which there are few. Hopefully this will continue to be the case, but since programs are getting bigger all the time, X and similar messages may become a necessity... :^( In that situation, standardized escaping would be a real bonus. > What would probably be more appropriate is to state how escaping is > performed where required as part of the base level protocol. Then in the > message put a statement like, "This message contains binary data and > must be Escaped using the standard escaping mechanism defined above". Right. If you've got to do it, at least make it consistent. > This way if you don't implement any of those messages, you don't need to > implement Escaping. But it advantageous in that it defines how escaping > will be used in any/all messages that require it. I think the same > should be said for RLE. Agreed. Maybe RLE and escaping go at the level that $#+- are at, instead of on a per-message basis, so the protocol will allow you to RLE or escape *any* message. I think that's what you're saying, anyway... > Maybe each message needs a check list that > states what features it may use like this: > > My new Message U My comments on this message Or maybe a new kind of query? I'm not sure I like that approach, but queries may have been created with stuff like this in mind. With only slightly more than a year of gdb under my belt, however, I don't have enough experience to say. Perhaps someone else does? b.g. -- William A. Gatliff Senior Design Engineer Komatsu Mining Systems ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Standard GDB Remote Protocol [not found] ` <3845F45A.38EA29CF@ozemail.com.au> [not found] ` <384685A7.15184EB1@haulpak.com> @ 1999-12-07 14:13 ` J.T. Conklin 1 sibling, 0 replies; 8+ messages in thread From: J.T. Conklin @ 1999-12-07 14:13 UTC (permalink / raw) To: Steven Johnson; +Cc: gdb >>>>> "Steven" == Steven Johnson <sbjohnson@ozemail.com.au> writes: >> Since you're putting up your hand, would you be willing to review the >> protocol spec and point out areas that are ambiguous, confusing, need >> revising, etc? Steven> Following is a Hopefully Constructive Critique, of the GDB Remote Steven> Protocol. Many thanks. I realize I'm late in this response, but I read your message as soon as it came in. I was quite pleased that you found so many issues so quickly. Steven> Packet Structure: Steven> Simple structure, obviously originally designed to be able to be driven Steven> manually from a TTY. (Hence it's ASCII nature.) However, the protocol Steven> has evolved quite significantly and I doubt it could still be used very Steven> efficiently from a TTY. That said, it still demarks frames effectively. I'm a bit more pessimistic. I believe that framing was effective in the original protocol (although I would have put the checksum inside the packet delimeters); but recent changes have muddied the distinc- tion between the debug protocol and the data link layer to the point where they are now inseparable. I think this is most unfortunate. Steven> Sequence Numbers: Steven> Definition of Sequence ID's needs work. Are they necessary? Are they Steven> deprecated? What purpose do they currently serve within GDB? One would Steven> imagine that they are used to allow GDB to handle retransmits from a Steven> remote system. Reading between the lines, this is done to allow error Steven> recovery when a transmission from target to host fails. Possible Steven> sequence being: I'm sure that you understand that we have to document the protocol as it is, rather than how we would like it to be. The protocol allows a good deal of flexibility in adding new commands, which GDB can use by probing the remote stub. This allows the protocol to evolve without requiring all existing stubs to be changed. Unfortunately, there is not a similar ability to change the data-link layer. The cases where we've done so (RLE, binary write) have had unfortunate consequences that were not realized until too late. That's a long and roundabout way of saying that sequence numbers have limited usefulness, and it will be difficult if not impossible to fix them. All a stub does is append the sequence number to the ack. GDB could use this to ensure that it's not misinterpreting the ACK for another packet or a '+' found within a packet, but it can't assume that stubs will reject subsequent packets with the same sequence number (duplic- ate packets). Another problem, not with the spec but with the implementation is that naks to packets with sequence numbers should also append the sequence number, but none of the sample stubs do this. Steven> <- $packet-data#checksum Steven> -> + Steven> -> $sequence-id:packet-data#checksum (checksum fails or receive timeout Steven> halfway through packet). Steven> <- -sequence-id Steven> -> $sequence-id:packet-data#checksum Steven> <- +sequence-id Steven> When do the sequence-id's increment? Presumably on the successful Steven> receipt of the +sequence-id acknowledgement. Steven> If they increment on the successful acknowledgement, what happens if the Steven> acknowledgement is in error? For example a framing error on the '+'. The Steven> target would never see the successful acknowledgement and would not Steven> increment it's sequence number. Steven> So what if it doesn't? The +/- Ack/Nak mechanism should be amply Steven> sufficient to allow retransmits of missed responses. Steven> I can see little practical benefit in a sequence-id in the responses, as Steven> it is currently documented. This is supported buy the comment within the Steven> document: "Beyond that its meaning is poorly defined. GDB is not known Steven> to output sequence-ids". This tends to indicate that the mechanism has Steven> fallen out of use, Probably because it doesn't actually achieve Steven> anything. If this is the case, it could be deprecated. However, I would Steven> advocate not deprecating it from the protocol, because If they were sent Steven> by GDB a current hole I believe is in the protocol could be plugged. (I Steven> will discuss this hole later in this critique.) Steven> Ack/Nak Mechanism: Steven> Simple Ack/Nak Mechanism, using + and - Respectively. Also Steven> reflects the simple ASCII basis of the protocol. My main Steven> concern with this system is there is no documentation of Steven> timing. Usually Ack/Nak must be received within a certain time Steven> frame, otherwise a Nak is assumed and a retransmit Steven> proceeds. This is necessary, because it is possible for the Steven> Ack/Nak character to be lost (however unlikely) on the line Steven> due to a data error. I think there should be a general timing Steven> basis to the entire protocol to tie up some potential Steven> communications/implementation problems. Yes, the protocol should talk about timeouts. IMHO the timeouts need to be presented as variables rather than absolutes, as the acceptable timeout will vary greatly depending on situation. There is GDB variable 'remotetimeout' which is used for timeouts, but there are more than one timeout should distinguish even if GDB and the stubs do not. Two that come to mind are the time between a packet is sent and an ack/nak is sent in response, and the time between a ack'd command is sent and a response is received. Steven> Once the $ character for the start of a packet is transmitted, each Steven> subsequent byte must be received within "n" byte transmission times. Steven> (This would allow for varying comms line speeds). Or alternately a Steven> global timeout on the whole message could be define one "$" (start Steven> sentinel) is sent, the complete message must be received within "X" Steven> time. I personally favour the inter character time as opposed to Steven> complete message time as it will work with any size message, As above, rather than come up with a heuristic like n * bit rate, or n ticks (in whatever unit) per packet, I believe that GDB must provide a variable (or variables) for timeouts. For example, both of the above would fail with a high latency connection, perhaps commands to a mars probe... Steven> One possible timeout that would be easy to work with could be: Steven> Timeout occurs 1 second after the last received byte. This might lose for very low bandwidth connections, perhaps commands to submerged submarines. Steven> For ACK/NAK I propose that something needs to be defined along Steven> the lines: ACK/NAK must be received within X Seconds from Steven> transmission of the end of the message, otherwise a NAK must Steven> be assumed. Steven> There is no documentation of the recovery procedure, Does GDB Steven> retransmit if its message is responded to with a NAK? If not, Steven> what does it do? How is the target supposed to identify and Steven> handle retransmits from GDB. GDB retransmits commands 3 times and gives up. This is a hardcoded constant --- there is no 'remoteretries' variable. Steven> What happens if something other than + or - is received when Steven> ACK/NAK is expected. (For example $). A '$' is assumed to be an old response. It then calls getpkt() to eat up the packet. Even if it is a packet, getpkt() is probably going to fail because the '$' has already been read. Any other character is considered to be junk and is discarded. There is no timeout so if the stub continuously spews junk, the connection will hang. Steven> If this is the intent of sequence-id and it has fallen into Steven> disuse, then to allow it's re-introduction at a later date, it Steven> could be documented that if GDB sends a sequence-id, then the Steven> retransmit processing I've documented here operates, otherwise Steven> the currently defined behaviour operates, and that sequence-id Steven> is only sent by the target in responses where they are present Steven> in the original GDB message. This would allow GDB to probe if Steven> the target supports secure and recoverable message delivery or Steven> not. I'm a bit fuzzy here. It's not clear how GDB can probe whether the stub supports a reliable transport, since there are so many stubs in the field that respond with an ack with an appended sequence number after receiving a packet with a sequence number. Steven> Run Length Encoding: Steven> Is run length encoding supported in all packets, or just some packets? Steven> (For example, not binary packets) It's supported on all packets from the target to GDB. It's unfortunate that this isn't symetric, because it would be most useful in one of the most issued commands: write all registers. Steven> Why not allow lengths greater than 126? Or does this mean lengths Steven> greater than 97 (as in 126-29) The run length is encoded as a printable ASCII value, so the run length should not be greater than 97. Steven> If binary packets with 8 bit data can be sent, why not allow Steven> RLE to use length also greater than 97. If the length maximum Steven> is really 126, then this yields the character 0x9B which is 8 Steven> bits, wouldn't the maximum length in this case be 226. Or is Steven> this a misprint? Packets with 8 bit values are still problematic. Even the probe GDB does to determine whether the binary memory write command exists is no guarentee that all possible values can be transmitted. Steven> Why are there 2 methods of RLE? Is it important for a Remote Steven> Target to understand and process both, or is the "cisco Steven> encoding" a proprietary extension of the GDB Remote protocol, Steven> and not part of the standard implementation. The documentation Steven> of "cisco encoding" is confusing and seems to conflict with Steven> standard RLE encoding. They appear to be mutually Steven> exclusive. If they are both part of the protocol, how are they Steven> distinguished when used? Some companies have made their own modifications to the remote protocol without consulting or working with the GDB maintainers. In some cases, they later decide to contribute their extensions. This is the case of the Cisco remote protocol extensions. GDB distinguishes the remote protocol and the Cisco varient by treating them as separate protocols that happen to share a lot of code. I still think the integration of Cisco's changes were not in the best interest of GDB. But one thing I think they did right was their implementation of RLE. At the expense of one extra character to express the run length, 256 bytes can be represented. Steven> Deprecated Messages: Steven> Should an implementation of the protocol implement the deprecated Steven> messages or not? What is the significance of the deprecated messages Steven> to the current implementation? I think not. Commands have been depricated because: * they were insufficently specified * were never implemented in a released GDB and/or sample debug stubs * were replaced by a better way of doing things. * etc. In the table of comands, I'd prefer that instead of some commands be marked 'optional', that the required commands (g/G/m/M/c) be marked required. Steven> Character Escaping: Steven> The mechanism of Escaping the characters is not Steven> defined. Further it is only defined as used by write mem Steven> binary. Wouldn't it be useful for future expansion of the Steven> protocol to define Character Escaping as a global feature of Steven> the protocol, so that if any control characters were required Steven> to be sent, they could be escaped in a consistent manner Steven> across all messages. Also, wouldn't the full list of escape Steven> characters be $,#,+,-,*,0x7d. Otherwise, + & - might be Steven> processed inadvertently as ACK or NAK. If this can't happen, Steven> then why must they be avoided in RLE? If they are escaped Steven> across all messages, then that means they could be used in RLE Steven> and not treated specially. IMO the problem with character stuffing is that it's happining at the protocol layer instead of the data link layer. You're right that the full list of characters should include '$', '#', '+', and '-'. Although GDB -> target RLE is not performed, '*' should be probably done done in case it is (or binary memory read) is implemented. In addition, I'd include characters with values 0-31 and 128-159 to avoid problems with serial links that don't handle control characters. Perhaps with some sort of data link negotiation that would open up larger windows. Another benefit with doing character stuffing at the data link layer is that it avoids dealing with variable length packets at the protocol layer. But I don't know how we could fix this now. Steven> 8/7 Bit protocol. Steven> With the documentation of RAW Binary transfers, the protocol moves from Steven> being a strictly 7 bit affair into being a 8 bit capable protocol. If Steven> this is so, then shouldn't all the restrictions that are placed from the Steven> 7 bit protocol days be lifted to take advantage of the capabilities of Steven> an 8 bit message stream. (RLE limitations, for example). Would anyone Steven> seriously be using a computer that had a 7 bit limitation anymore Steven> anyway? (At least a computer that would run GDB with remote debugging). I'm more concerned with the other side than the GDB side. I can imagine a target that could only reasonably support a 7 bit channel. Steven> Thoughts on consistency and future growth: Steven> Apply RLE as a feature of All messages. (Including binary messages, as Steven> these can probably benefit significantly from it). Steven> Apply the Binary Escaping mechanism as a feature of the packet that is Steven> performed on all messages prior to transmission and immediately after Steven> reception. Define an exhaustive set of "Characters to be escaped". Steven> Introduce message timing constraints. Steven> Properly define sequence-id and allow it to be used from GDB to make Steven> communications secure and reliable. These are all great, but I'm not sure how much can been within the confines of the existing protocol. --jtc -- J.T. Conklin RedBack Networks From jtc@redback.com Tue Dec 07 14:53:00 1999 From: jtc@redback.com (J.T. Conklin) To: Bill Gatliff <gatliff@haulpak.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 14:53:00 -0000 Message-id: <5miu2az7lb.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> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com> <38470CC1.1B0E5C27@ozemail.com.au> <3847C872.55287A40@haulpak.com> X-SW-Source: 1999-q4/msg00467.html Content-length: 2355 >>>>> "Bill" == Bill Gatliff <gatliff@haulpak.com> writes: >> This way if you don't implement any of those messages, you don't need to >> implement Escaping. But it advantageous in that it defines how escaping >> will be used in any/all messages that require it. I think the same >> should be said for RLE. Bill> Agreed. Maybe RLE and escaping go at the level that $#+- are at, Bill> instead of on a per-message basis, so the protocol will allow you Bill> to RLE or escape *any* message. I think that's what you're saying, Bill> anyway... Had binary data been quoted at the data link layer, the implementation would have been a lot simpler and likely more robust. I wish I would have noticed this back when I objected to binary write being added as 4.18 was being released. Unfortunately, I can't see how we can do this in a compatible manner. The character stuffing increases the packet length. The memory write command compensates by reducing the length of the data being written, resulting in a packet < PBUFSIZ. Ideally you don't want the protocol layer to know these kind of details --- only the link layer MTU. This would work fine if both GDB and the stub did quoting at the link layer. Gdb could send a packet that, after stuffing, was larger than PBUFSIZ. But this would not be a problem because the new stub would un-stuff (and un-rle) packets as they are received. But if such a GDB was communicating to a stub that didn't unstuff until the 'X' command was processed, packet buffers may overflow. >> Maybe each message needs a check list that >> states what features it may use like this: >> >> My new Message U My comments on this message Bill> Or maybe a new kind of query? I'm not sure I like that Bill> approach, but queries may have been created with stuff like this Bill> in mind. With only slightly more than a year of gdb under my Bill> belt, however, I don't have enough experience to say. Perhaps Bill> someone else does? Perhaps we could have a query command used determine data link layer capabilities. It would have to be issued at the initial connection, and would have to be issued with the least-common-denominator 7 bit query, no-rle, framing. It's a bit ugly... I don't like it... but it probably could be made to work. --jtc -- J.T. Conklin RedBack Networks From jimb@cygnus.com Tue Dec 07 15:07:00 1999 From: Jim Blandy <jimb@cygnus.com> To: gdb@sourceware.cygnus.com Subject: i386 info float Date: Tue, 07 Dec 1999 15:07:00 -0000 Message-id: <199912072307.SAA02179@zwingli.cygnus.com> X-SW-Source: 1999-q4/msg00468.html Content-length: 1367 We were notified yesterday that the FSF had received the copyright papers for Mark's `info float' command, so it's in the sources now. It should appear in the next snapshot. Thanks very much, Mark! Persons of proper upbringing will be shocked to learn that there are no less than eight distinct implementations of `info float' for the x86. Now, the Sequent machines do have the Weitek FPU, so one could plausibly argue that they merit their own `info float' command. But they don't. (As far as I can tell.) So the duplication is completely gratuitous. They are as follows: The one we want to keep: i387-tdep.c:i387_float_info Maintained platforms: go32-nat.c:i386_go32_float_info (Eli's bailiwick) i386gnu-nat.c:i386_mach3_float_info (Mark's bailiwick) i386b-nat.c:i386_float_info (used on all BSD's; any takers?) i386v-nat.c:i386_float_info (#if 0'd out) Unmaintained platforms (as far as I know): i386m3-nat.c:i386_mach3_float_info (unmaintained) i386aix-nat.c:i386_float_info (unmaintained) symm-nat.c:i386_float_info (unmaintained) I'm going to delete the definition from i386v-nat.c. As far as I know, there are no BSD GDB folks participating in this list, so we'll just have to wait until someone speaks up about them. So, once Eli and Mark have taken care of their targets, we're basically done. From jtc@redback.com Tue Dec 07 15:33:00 1999 From: jtc@redback.com (J.T. Conklin) To: William Gatliff <gatliff@haulpak.com> Cc: gdb@sourceware.cygnus.com Subject: Re: Standard GDB Remote Protocol Date: Tue, 07 Dec 1999 15:33:00 -0000 Message-id: <5md7siz5qb.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> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com> X-SW-Source: 1999-q4/msg00469.html Content-length: 2083 >>>>> "William" == William Gatliff <gatliff@haulpak.com> writes: William> If efficiency/throughput is a problem, then go to ethernet. William> At 10/100Mbps, even the overhead of ASCII isn't a problem for William> most targets I can think of. Yet the protocol should be as efficent as possible. For many targets, ethernet and a TCP/IP stack is a heavyweight requirement. I looked at cleanly separating the layers in remote.c so I could use UDP some time ago. About the same time, the mini-telnet stuff came in which assumes a stream transport. Bleh. Steven> I think there should be a general timing basis to the entire Steven> protocol to tie up some potential communications/ Steven> implementation problems. William> The RSP's lack of timing requirements is an asset, as far as I'm William> concerned. See below. Although Steven mentioned several alternatives of computing timeout values from bit rate, message size, etc.; I believe that those are secondary to his point that the protocol should identify that time- outs are necessary to guarantee a reliable. Once they are identified, the lengths of those timeouts can be implemented by GDB variables or manifest constants in stub code, etc. But without them, I think that we'll continue to have weaknesses in both. Steven> Character Escaping: The mechanism of Escaping the characters is not Steven> defined. Further it is only defined as used by write mem binary. William> That's because this is the only place where it is needed, William> AFAIK. It's the only place where it's used now. But I wouldn't go so far as saying that it's the only place where it's needed. Perhaps even more useful than binary memory write is binary register write. Registers are written quite often while stepping through a program. Likewise, it would be useful to have a binary memory read and binary register read. IMO, using the same escaping mechanisms for all such commands would be good thing. To do so, I'd put it at the data link layer instead of inside each command. --jtc -- J.T. Conklin RedBack Networks From jtc@redback.com Tue Dec 07 15:49: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: Tue, 07 Dec 1999 15:49:00 -0000 Message-id: <5m9036z518.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> <38478423.6ACE7BF8@cygnus.com> X-SW-Source: 1999-q4/msg00470.html Content-length: 1301 >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes: Andrew> How GDB behaves should be clarified. However, any definition should Andrew> avoid refering to absolute times and instead refer the user back to a Andrew> number of knobs that can be tweeked from the GDB command line. Steven is/was examining the protocol specification without the GDB and stub sources to avoid becoming biased by exposure. In addition, I recommend that, at least at the present time, this also be true of GDB's variables. If Steven is willing to carry this a bit farther, I'd like to see the protocol defined in terms of 'variables' which can be later mapped to GDB's variables. Or in the case where GDB does not have such a user configurable varible, a concious decision can be made whether to add one or continue using whatever constant is in the source. For example, this thread has me thinking that there are actually two separate timeouts in the protocol. The timeout from when a packet is sent and it is ACK/NAKed. And a timeout from when a command is sent and it's response is received. At the present time, 'remotetimeout' is used for both purposes. But it's reasonable to set the first to a short value and the latter to something much larger. --jtc -- J.T. Conklin RedBack Networks From ac131313@cygnus.com Tue Dec 07 16:08:00 1999 From: Andrew Cagney <ac131313@cygnus.com> To: jtc@redback.com Cc: pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com Subject: Re: Exist a 68k simulator? Date: Tue, 07 Dec 1999 16:08:00 -0000 Message-id: <384DA0FF.86D558DF@cygnus.com> References: <NDBBLKOACKKKFPINNIPEOEKGCAAA.pschen@puma.cs.nthu.edu.tw> <5mwvqqzh1s.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q4/msg00471.html Content-length: 376 "J.T. Conklin" wrote: > > Where can I find a 68k simulator? ( want to put in /sim directory) > > Isn't there 68k simulator used in the PalmPilot and that coin-op video > game emulator? Do the licences for those allow for inclusion within > GDB? No one is exactly clear on that one. If the answer had been yes, it would have been integrated long ago :-) enjoy, Andrew From jsm@cygnus.com Tue Dec 07 16:17:00 1999 From: Jason Molenda <jsm@cygnus.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: jtc@redback.com, pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com Subject: Re: Exist a 68k simulator? Date: Tue, 07 Dec 1999 16:17:00 -0000 Message-id: <19991207161726.B20332@cygnus.com> References: <NDBBLKOACKKKFPINNIPEOEKGCAAA.pschen@puma.cs.nthu.edu.tw> <5mwvqqzh1s.fsf@jtc.redbacknetworks.com> <384DA0FF.86D558DF@cygnus.com> X-SW-Source: 1999-q4/msg00472.html Content-length: 1056 On Wed, Dec 08, 1999 at 11:06:23AM +1100, Andrew Cagney wrote: > "J.T. Conklin" wrote: > > > > Where can I find a 68k simulator? ( want to put in /sim directory) > > > > Isn't there 68k simulator used in the PalmPilot and that coin-op video > > game emulator? Do the licences for those allow for inclusion within > > GDB? > > No one is exactly clear on that one. If the answer had been yes, it > would have been integrated long ago :-) I'll repeat the plug for the Unix Amiga Emulator projects' 68000/68020/68881 simulator. http://www.freiburg.linux.de/~uae/ I talked to the author/maintainer, Bernd Schmidt, about using it in GDB a while ago. He expect no problems. It is GPL'ed. It is not the most complete 68k simulator in the world, but he expected that it would handle gcc-generated code OK. It has been appropriated by several other projects as a generic CPU simulator in the past. I don't have time to pursue this any further right now, but that looks like a very good avenue to pursue if someone wanted to pull in a 68k simulator. J From ac131313@cygnus.com Tue Dec 07 16:32: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: Tue, 07 Dec 1999 16:32:00 -0000 Message-id: <384DA6B9.339ED90D@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/msg00473.html Content-length: 1464 "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes: > Andrew> How GDB behaves should be clarified. However, any definition should > Andrew> avoid refering to absolute times and instead refer the user back to a > Andrew> number of knobs that can be tweeked from the GDB command line. > > Steven is/was examining the protocol specification without the GDB > and stub sources to avoid becoming biased by exposure. In addition, > I recommend that, at least at the present time, this also be true of > GDB's variables. > > If Steven is willing to carry this a bit farther, I'd like to see the > protocol defined in terms of 'variables' which can be later mapped to > GDB's variables. Or in the case where GDB does not have such a user > configurable varible, a concious decision can be made whether to add > one or continue using whatever constant is in the source. That would be bliss. > For example, this thread has me thinking that there are actually two > separate timeouts in the protocol. The timeout from when a packet is > sent and it is ACK/NAKed. And a timeout from when a command is sent > and it's response is received. At the present time, 'remotetimeout' > is used for both purposes. But it's reasonable to set the first to a > short value and the latter to something much larger. There is also (as noted earlier) the time between each character that arrives. GDB uses the same timeout for that. Andrew From ac131313@cygnus.com Tue Dec 07 17:03: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: Tue, 07 Dec 1999 17:03:00 -0000 Message-id: <384DAE26.241BCE2B@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/msg00474.html Content-length: 2366 "J.T. Conklin" wrote: > > Steven> 8/7 Bit protocol. > Steven> With the documentation of RAW Binary transfers, the protocol moves from > Steven> being a strictly 7 bit affair into being a 8 bit capable protocol. If > Steven> this is so, then shouldn't all the restrictions that are placed from the > Steven> 7 bit protocol days be lifted to take advantage of the capabilities of > Steven> an 8 bit message stream. (RLE limitations, for example). Would anyone > Steven> seriously be using a computer that had a 7 bit limitation anymore > Steven> anyway? (At least a computer that would run GDB with remote debugging). > > I'm more concerned with the other side than the GDB side. I can > imagine a target that could only reasonably support a 7 bit channel. Yes, it's optional for that reason (and yes, the spec should clarify that :-) > Steven> Thoughts on consistency and future growth: > Steven> Apply RLE as a feature of All messages. (Including binary messages, as > Steven> these can probably benefit significantly from it). > > Steven> Apply the Binary Escaping mechanism as a feature of the packet that is > Steven> performed on all messages prior to transmission and immediately after > Steven> reception. Define an exhaustive set of "Characters to be escaped". > > Steven> Introduce message timing constraints. > Steven> Properly define sequence-id and allow it to be used from GDB to make > Steven> communications secure and reliable. > > These are all great, but I'm not sure how much can been within the > confines of the existing protocol. As a vague suggestion of a ``five year'' gdb-protocol plan: v2.0: Formalize the lower layers (transport, ...?) (Where's my AST networks book :-) and address issues such as reliability. The command set would remain the same - warts and all. v3.0: Look at the actual gdb command set If the two can be separated then, there is some hope of being able to move forward. As an incentive, the getpkt() and putpkt() functions and several chunks of remote.c need a further rewrite any way. They should to be inverted so that they are based on an event model. Clearly separating the layers would help this. The alternative, as always, is to start again from scratch. Andrew (As for the mini-telnet, if someone would like to propose a decent telnet extenstion to the protocol then, I'm all ears) From shebs@cygnus.com Tue Dec 07 17:41:00 1999 From: Stan Shebs <shebs@cygnus.com> To: jsm@cygnus.com Cc: cagney@cygnus.com, jtc@redback.com, pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com Subject: Re: Exist a 68k simulator? Date: Tue, 07 Dec 1999 17:41:00 -0000 Message-id: <199912080138.RAA27224@andros.cygnus.com> References: <19991207161726.B20332@cygnus.com> X-SW-Source: 1999-q4/msg00475.html Content-length: 962 Date: Tue, 7 Dec 1999 16:17:26 -0800 From: Jason Molenda <jsm@cygnus.com> I'll repeat the plug for the Unix Amiga Emulator projects' 68000/68020/68881 simulator. http://www.freiburg.linux.de/~uae/ I talked to the author/maintainer, Bernd Schmidt, about using it in GDB a while ago. He expect no problems. It is GPL'ed. It is not the most complete 68k simulator in the world, but he expected that it would handle gcc-generated code OK. It has been appropriated by several other projects as a generic CPU simulator in the past. I don't have time to pursue this any further right now, but that looks like a very good avenue to pursue if someone wanted to pull in a 68k simulator. Indeed, this would be a good project for someone that wanted to get their feet wet in embedded GDB hacking. The technical parts are not too hard, you don't need special hardware, and people will appreciate the contribution. Stan ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <38478987.EECEEBF@cygnus.com>]
[parent not found: <199912061134.GAA16617@mescaline.gnu.org>]
[parent not found: <npk8msaqoo.fsf@zwingli.cygnus.com>]
* Re: ST(i) and MMj [not found] ` <npk8msaqoo.fsf@zwingli.cygnus.com> @ 1999-12-08 1:46 ` Eli Zaretskii [not found] ` <npogc1afwn.fsf@zwingli.cygnus.com> 0 siblings, 1 reply; 8+ messages in thread From: Eli Zaretskii @ 1999-12-08 1:46 UTC (permalink / raw) To: jimb; +Cc: ac131313, gdb > > * 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 <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, ®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 <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 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <npogc1afwn.fsf@zwingli.cygnus.com>]
[parent not found: <199912091029.FAA13387@mescaline.gnu.org>]
* Re: ST(i) and MMj [not found] ` <199912091029.FAA13387@mescaline.gnu.org> @ 1999-12-10 5:51 ` Andrew Cagney 0 siblings, 0 replies; 8+ messages in thread From: Andrew Cagney @ 1999-12-10 5:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: jimb, gdb 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1999-12-10 5:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <199911090706.CAA13120@zwingli.cygnus.com>
[not found] ` <199911102246.RAA01846@mescaline.gnu.org>
[not found] ` <npr9hi321d.fsf@zwingli.cygnus.com>
[not found] ` <199911231303.IAA01523@mescaline.gnu.org>
[not found] ` <npr9hg2a9t.fsf@zwingli.cygnus.com>
[not found] ` <199911251715.MAA09225@mescaline.gnu.org>
1999-11-30 10:20 ` none Jim Blandy
1999-12-01 0:21 ` ST(i) and MMj Eli Zaretskii
[not found] ` <npogca9tb8.fsf@zwingli.cygnus.com>
[not found] ` <3845AB0E.3795D99E@ozemail.com.au>
1999-12-01 15:43 ` Standard GDB Remote Protocol Quality Quorum
1999-12-01 15:53 ` Stan Shebs
[not found] ` <5md7sql00o.fsf@jtc.redbacknetworks.com>
[not found] ` <3845F45A.38EA29CF@ozemail.com.au>
[not found] ` <384685A7.15184EB1@haulpak.com>
[not found] ` <38470CC1.1B0E5C27@ozemail.com.au>
1999-12-03 5:41 ` Bill Gatliff
1999-12-07 14:13 ` J.T. Conklin
[not found] ` <38478987.EECEEBF@cygnus.com>
[not found] ` <199912061134.GAA16617@mescaline.gnu.org>
[not found] ` <npk8msaqoo.fsf@zwingli.cygnus.com>
1999-12-08 1:46 ` ST(i) and MMj Eli Zaretskii
[not found] ` <npogc1afwn.fsf@zwingli.cygnus.com>
[not found] ` <199912091029.FAA13387@mescaline.gnu.org>
1999-12-10 5:51 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox