From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: gatliff@haulpak.com Cc: gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Fri, 13 Aug 1999 15:08:00 -0000 Message-id: <199908132208.PAA19753@andros.cygnus.com> References: <37B419FD.C9748ABE@haulpak.com> X-SW-Source: 1999-q3/msg00167.html Date: Fri, 13 Aug 1999 08:13:33 -0500 From: William Gatliff > 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. On the embedded side, could RTOS support be made a stub issue, instead of a gdb issue? As an embedded developer, I find it much easier to add/modify a stub than to muck around with the internals of gdb itself. If there were a standard set of RDP messages that could be used to deliver OS information from a stub back to gdb, then I would be happy to add stub support for my own RTOS, whatever that happens to be, using the RTOS's native calls. That was kicked around a bit in our internal (ahem :-) ) discussion. Basically you ask the RTOS "what kinda objects you got?", get back a list of types, then ask "how should type X be displayed?" and get back something like a printf format string or maybe even a bit of XML, then GDB follows instructions when getting the objects' data and displaying it. eCos and other folks observed that this was probably too heavyweight to impose on every RTOS, although it would make sense for the larger OSes. Also, you still have the dumpfile problem that JT alluded to, where you don't necessarily have a live target to run a stub. So while it would be preferable to put OS-specific bits on the target side, the design needs to accommodate the possibility that all the IQ is living on the host somewhere. Stan >From jtc@redback.com Fri Aug 13 16:49:00 1999 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: Code in can_use_hardware_watchpoint() Date: Fri, 13 Aug 1999 16:49:00 -0000 Message-id: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00168.html Content-length: 1164 I believe the enclosed code from can_use_hardware_watchpoint() has a problem, but I'm unsure of the proper fix. The problem is that a expression containing a register variable will not cause this function to fail (return 0). This seems to result in GDB forging ahead and placing a hardware watchpoint at a random address for the register variable. An example of this is something like 'watch mem[reg] != 0'. /* Make sure all the intermediate values are in memory. Also make sure we found at least one memory expression. Guards against watch 0x12345, which is meaningless, but could cause errors if one tries to insert a hardware watchpoint for the constant expression. */ for (; v; v = v->next) { if (v->lval == lval_memory) { if (TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (TYPE_LENGTH (VALUE_TYPE (v)))) found_memory_cnt++; } else if (v->lval != not_lval && v->modifiable == 0) return 0; } One solution is to add an: else if (v->lval == lval_register) return 0; But I'm wondering if instead the v->modifiable == 0 should be == 1 instead. --jtc -- J.T. Conklin RedBack Networks >From eliz@gnu.org Sun Aug 15 05:34:00 1999 From: Eli Zaretskii To: gdb@sourceware.cygnus.com Cc: jtc@redback.com (J.T. Conklin) Subject: Re: Code in can_use_hardware_watchpoint() Date: Sun, 15 Aug 1999 05:34:00 -0000 Message-id: <199908151234.IAA14013@mescaline.gnu.org> References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00169.html Content-length: 730 From: jtc@redback.com (J.T. Conklin) Date: 13 Aug 1999 16:49:25 -0700 > I believe the enclosed code from can_use_hardware_watchpoint() has a > problem, but I'm unsure of the proper fix. As long as we are talking about this function, here's another question: shouldn't the loop below return zero as soon as the first value is found on the value chain that is NOT okay to watch (as the macro TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT says)? for (; v; v = v->next) { if (v->lval == lval_memory) { if (TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT (TYPE_LENGTH (VALUE_TYPE (v)))) found_memory_cnt++; } else if (v->lval != not_lval && v->modifiable == 0) return 0; } >From jimb@cygnus.com Sun Aug 15 23:28:00 1999 From: Jim Blandy To: Stan Shebs Cc: jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Sun, 15 Aug 1999 23:28:00 -0000 Message-id: References: <199908132135.OAA19734@andros.cygnus.com> X-SW-Source: 1999-q3/msg00170.html Content-length: 1974 As long as we're talking about philosophy... I agree very much with Stan that GDB should be a bag of tools that just works, without getting fussy about exactly which features you configured in, and which you left out. I come closest to throwing a tantrum when I have to struggle with my debugger while debugging something else, under a deadline. And I'm on Cygnus's GDB team --- what's it like for someone else? However, I am concerned about the approach described here, which I suspect is really at the heart of JT's concerns: Ultimately I'd like to see more modularity for system-specific bits, but we're not there yet, and I don't want to see users switching to other debuggers because we're waiting for somebody to write more elegant code. I read this as, "We will integrate features people want even if they are non-modular. Doing them in a modular way takes too much time. We'll get around to it eventually." I don't think this approach is long-term sustainable. We don't need modularity because it's beautiful --- we need modularity because, although we are under deadlines now, we will also be under deadlines a year from now. Or two years from now. Beauty and modularity are different. GDB's processor architecture interface (pre multi-arch) is modular, but not beautiful. We support, what, twenty different processors? But clearly, you can work on GDB without knowing them all. So that's a successful structuring. The problem with the Cisco changes is that they're just sort of mixed in with the remote stuff (among other things), which ought to be staying really simple. When I want to understand how remote.c works, I need to read the Cisco stuff just to reassure myself that it isn't relevant. Is everyone prepared to jump into remote.c for a contract, now that it's grown from 3500 lines (June 6) to 5240 lines (Aug 5)? I don't have specific ideas for how to fix this, though. But I do think JT's identified a real problem. >From ac131313@cygnus.com Sun Aug 15 23:47:00 1999 From: Andrew Cagney To: Jim Blandy Cc: Stan Shebs , jtc@redback.com, gdb@sourceware.cygnus.com Subject: Re: What's with all the Cisco stuff? Date: Sun, 15 Aug 1999 23:47:00 -0000 Message-id: <37B7B399.714F00DC@cygnus.com> References: <199908132135.OAA19734@andros.cygnus.com> X-SW-Source: 1999-q3/msg00171.html Content-length: 770 Jim Blandy wrote: > The problem with the Cisco changes is that they're just sort of mixed > in with the remote stuff (among other things), which ought to be > staying really simple. When I want to understand how remote.c works, > I need to read the Cisco stuff just to reassure myself that it isn't > relevant. Is everyone prepared to jump into remote.c for a contract, > now that it's grown from 3500 lines (June 6) to 5240 lines (Aug 5)? Just to expand on this a little. Two things caused remote.c to expand. The more important one was that I recommending to Elena that a patch adding the targets ``async'' and ``extended-async'' be committed. In the future those targets will be absorbed into more familar ``remote'' and ``extended-remote''. enjoy, Andrew >From jimb@cygnus.com Sun Aug 15 23:50:00 1999 From: Jim Blandy To: Kevin Buettner Cc: gdb@sourceware.cygnus.com Subject: Re: Temporary breakpoints Date: Sun, 15 Aug 1999 23:50:00 -0000 Message-id: References: <199908120252.TAA25463@elmo.cygnus.com> X-SW-Source: 1999-q3/msg00172.html Content-length: 1484 > 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. 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. 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. >From jimb@cygnus.com Mon Aug 16 00:04:00 1999 From: Jim Blandy To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: Code in can_use_hardware_watchpoint() Date: Mon, 16 Aug 1999 00:04:00 -0000 Message-id: References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00173.html Content-length: 640 I'm not really familiar with this code, but: > One solution is to add an: > > else if (v->lval == lval_register) > return 0; I think this is the right thing. The value chain is supposed to be a list of all the values generated while evaluating the watchpoint's expression. (What if someone else generates a value in the mean time? Don't you think it's a bad idea to draft a list intended for storage management into use in expression analysis? Bleah.) If you find anything on there that could change, but can't be watched, you should return zero. But the fix seems so obvious there must be something else going on... >From law@cygnus.com Mon Aug 16 00:40:00 1999 From: "Jeffrey A. Law" To: jimb@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: Code in can_use_hardware_watchpoint() Date: Mon, 16 Aug 1999 00:40:00 -0000 Message-id: <199908160740.AAA18545@rtl.cygnus.com> References: <5mu2q3jl6i.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00174.html Content-length: 1483 In article < np672gury4.fsf@zwingli.cygnus.com > you write: >I'm not really familiar with this code, but: > >> One solution is to add an: >> >> else if (v->lval == lval_register) >> return 0; > >I think this is the right thing. > >The value chain is supposed to be a list of all the values generated >while evaluating the watchpoint's expression. (What if someone else >generates a value in the mean time? Don't you think it's a bad idea >to draft a list intended for storage management into use in expression >analysis? Bleah.) If you find anything on there that could change, >but can't be watched, you should return zero. I agree with Jim (and I am somewhat familiar with the code, though most of the details have become fuzzy over the years). Basically we have to build a list of all the expressions/values which are required to evaluate a watchpoint. If anything on that list of values can not be watched with a hardware watchpoint, then we do not allow hardware watchpoints to be used. >But the fix seems so obvious there must be something else going on... I don't think so. I think it's just a case we didn't properly think through. If the only value on the chain was a reg, then we'd be OK because we would not have found a memory location. But if we try to watch p->q and P is in a reg, then we'd lose. At one time that code may have done an "else return 0;", but that may have been kicking out too many things which it should have accepted. jeff >From wmann@avici.com Mon Aug 16 06:17:00 1999 From: Bill Mann To: Jim Blandy , Kevin Buettner Cc: gdb@sourceware.cygnus.com Subject: Re: Temporary breakpoints Date: Mon, 16 Aug 1999 06:17:00 -0000 Message-id: <4.1.19990816090334.00c4fd70@mailhost.avici.com> References: <11> <1999> <19:52:45> <-0700> <(PDT)> <199908120252.TAA25463@elmo.cygnus.com> X-SW-Source: 1999-q3/msg00175.html Content-length: 2222 At 01:49 AM 8/16/99 -0500, 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. Right! >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. But I think that's not the way it should work. If I set a breakpoint, then step over it, I want the breakpoint to be hit. I want it to print what it would normally print, or count if it's a multiple proceed, or execute special commands if they are defined. I see a breakpoint as a temporary patch to my program, and I want single step to honor that patch (as a unit). >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. But what's different about internal breakpoints? All breakpoints should work like this. If there are several breakpoints at the same location, they should all be executed, one after the other, but only return interactive control to the user if one or more of them don't 'continue'. >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.