From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: none Date: Tue, 30 Nov 1999 10:20:00 -0000 Message-id: References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> X-SW-Source: 1999-q4/msg00366.html > > 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 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 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 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 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 > 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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