From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: gdb@sourceware.cygnus.com Subject: Re: Temporary breakpoints Date: Mon, 16 Aug 1999 09:00:00 -0000 Message-id: <37B83421.868DF89A@cygnus.com> References: <199908120252.TAA25463@elmo.cygnus.com> X-SW-Source: 1999-q3/msg00177.html Jim Blandy wrote: > > I have a question regarding temporary breakpoints... > > > > Under what circumstances should a temporary breakpoint be deleted? > > It should be deleted under the same circumstances in which GDB tells > the user it has been hit. A temporary breakpoint is a user-visible > construct (unlike many breakpoints in GDB), so its behavior must be > consistent from the user's point of view. This is a sensible position to take and I think I am starting to favor this point of view. When I was in Sunnyvale last week, Jim Ingham made a convincing argument for leaving the temporary breakpoint intact. His argument goes like this... when you have a fairly complicated GDB session with a number of breakpoints, you're likely to forget where all of your breakpoints are. When you enter a bit of code through some other pathway that causes you as the user of the debugger to start single stepping, you may well forget that you're about to step onto one of your temporary breakpoints. If you step over it and it gets deleted, the harm caused by deleting this breakpoint is greater than leaving it in (assuming of course that you want it left in). I.e, there's very little harm incurred by leaving it in and then hitting it (as a result of continuing) at some later point. Rereading the above, I don't think I was able to do justice to Jim's argument. Jim, if you're reading this, you may want to reply with a more cogently worded version... > GDB does not report a breakpoint hit if it occurs exactly when GDB > would have stopped stepping anyway. So, if you set a breakpoint on > the first instruction of a line, and "step" to it, GDB won't report a > hit, because it would have stopped there anyway. If you set a > breakpoint on an instruction in the middle of the line, GDB will > report it, because you've stopped in an unusual place. But if you > stepi, then GDB will never report a breakpoint hit. At the present time, the behavior of gdb with regard to reporting that a breakpoint has been hit due to single stepping depends on the platform on which you are running gdb: Linux/x86 does not report that the breakpoint has been hit. Solaris/sparc does report that the breakpoint has been hit. I haven't tried other platforms (yet), but I suspect that the behavior will depend upon whether or not a single step is implemented via breakpoints or in hardware. (If it's implemented in hardware, you won't see the message.) I think the breakpoint should be reported hit regardless of whether you're single stepping or not (and regardless of the implementation). If we're going to delete temporary breakpoints when they're hit due to single stepping, this is particularly important so that the user can re-set the temporary breakpoint if it's important to him. > It's worth noting that a breakpoint's behavior depends on its intended > use. Breakpoints which GDB uses to implement some internal feature > should behave differently from user-level breakpoints. For example, > the breakpoint which GDB uses to tell when a new shared library has > been loaded should be considered "hit" even if you reach it via stepi, > or even if the user has set another breakpoint on top of it --- > otherwise, GDB will miss the event it was waiting for. > > This is what that hairy, worthless table in bpstat_what is all about. > Note that the whole table could be replaced by a call to `max' and a > little logic, if someone wants to take the time. Kevin >From jtc@redback.com Mon Aug 16 13:27:00 1999 From: jtc@redback.com (J.T. Conklin) To: Stan Shebs Cc: gatliff@haulpak.com, gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Mon, 16 Aug 1999 13:27:00 -0000 Message-id: <5mn1vriieb.fsf@jtc.redbacknetworks.com> References: <199908132208.PAA19753@andros.cygnus.com> X-SW-Source: 1999-q3/msg00178.html Content-length: 3374 >>>>> "Stan" == Stan Shebs writes: Stan> Date: Fri, 13 Aug 1999 08:13:33 -0500 From: William Gatliff Stan> >> I would ecstatic with more interest and input here. "RTOS support" >> is an area where GDB gets hammered relative to its competition, and >> display of kernel objects is a specific feature that gets comes up >> frequently. Stan> On the embedded side, could RTOS support be made a stub Stan> issue, instead of a gdb issue? As an embedded developer, I Stan> find it much easier to add/modify a stub than to muck around Stan> with the internals of gdb itself. Stan> If there were a standard set of RDP messages that could be Stan> used to deliver OS information from a stub back to gdb, then Stan> I would be happy to add stub support for my own RTOS, Stan> whatever that happens to be, using the RTOS's native calls. Stan> That was kicked around a bit in our internal (ahem :-) ) Stan> discussion. Basically you ask the RTOS "what kinda objects you Stan> got?", get back a list of types, then ask "how should type X be Stan> displayed?" and get back something like a printf format string Stan> or maybe even a bit of XML, then GDB follows instructions when Stan> getting the objects' data and displaying it. The "how should type X be displayed?" question IMO is inappropriate. The target knows the kernel objects and their types, but the user is in a better position to know how they are to be displayed (or other- wise manipulated). I've thought about this a bit, and it seems the best model to use is something like SNMP. But instead of a pre-defined MIB that is known by both the debug agent on the target and GDB, the MIB is downloaded from the target. There should probably be traps so the debug agent can tell GDB that new MIBs are present or old ones have been removed if the kernel has loadable kernel modules or the like. A `kod' command would take the name of an object to fetch, returning a value that could be used in other GDB expressions. set $threads = kod system.threads if ($maxthreads < $threads) set $maxthreads = $threads end Perhaps an incompletely specified MIB entry would return a vector containing the values in the entire MIB hierarchy? With SNMPv1-like get & get-next requests, extracting tables would be nearly as inefficent as GDB scripts that grovel through memory. I'm not familiar with the SNMPv2 get-bulk request, but from what's been described to me, something like that could be used to improve performance. Stan> eCos and other folks observed that this was probably too Stan> heavyweight to impose on every RTOS, although it would make Stan> sense for the larger OSes. Even though I walked through the above thought experiment, I'm still not convinced that direct access to kernel data structures with GDB scripts is not superior. In my opinion, KOD must be much more than a kernel object pretty-printer to justify its exisistance. Individual objects must be able to be queried and their values must be usable in GDB expressions. This model requires quite a bit of hair to create an abstraction layer between kernel objects and GDB. I'm not sure that that abstraction provides enough benefits to overcome the complexity in an OS of any size. --jtc -- J.T. Conklin RedBack Networks >From gatliff@haulpak.com Mon Aug 16 13:58:00 1999 From: William Gatliff To: jtc@redback.com Cc: Stan Shebs , gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Mon, 16 Aug 1999 13:58:00 -0000 Message-id: <37B87B49.268721B5@haulpak.com> References: <199908132208.PAA19753@andros.cygnus.com> <5mn1vriieb.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00179.html Content-length: 1275 > Stan> eCos and other folks observed that this was probably too > Stan> heavyweight to impose on every RTOS, although it would make > Stan> sense for the larger OSes. > > Even though I walked through the above thought experiment, I'm still > not convinced that direct access to kernel data structures with GDB > scripts is not superior. I agree completely-- keeping a "thin" stub is definitely the way to go. In retrospect, what I'm after may be something less related to what you guys are talking about than I thought... If I'm trying to make gdb "aware" of an RTOS like uC/OS or eCos, for which I have sources, then the kernel data structures should exist as symbols, so I should be able to peek/poke at them with regular gdb functionality when the target stops. OTOH, the threading stuff needs more OS support that's best handled in the stub (at least for runtime performance reasons): the stub can use whatever kernel calls are available to check the active thread when a TRAP occurs, and keep going when it's the wrong one. This doesn't require any gdb support at all, except that the continue is hard to do if gdb has already clobberred the original opcode with the breakpoint isn... b.g. -- William A. Gatliff Senior Design Engineer Komatsu Mining Systems