From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Mark Salter Cc: gdb-patches@sources.redhat.com Subject: Re: Remote watchpoint support. Date: Mon, 30 Oct 2000 12:21:00 -0000 Message-id: <39FDD845.680@redhat.com> References: <200010301416.e9UEG6m18981@deneb.localdomain> <39FDCF55.46BD@redhat.com> <200010302018.e9UKIr300876@deneb.localdomain> X-SW-Source: 2000-10/msg00278.html Mark Salter wrote: > > >>>>> Michael Snyder writes: > > > Mark Salter wrote: > >> > >> I'm adding hw break/watchpoint support to a remote target. I'm using > >> the Z-packet support that is in remote.c to install/remove the > >> watchpoints and breakpoints. When a watchpoint is triggered by a > >> read access, GDB needs a way to tell if the target stopped because > >> of the watchpoint. This is done through a target specific function: > >> > >> CORE_ADDR target_stopped_data_address(void) > >> > >> which returns the address of the data access which triggered the > >> watchpoint. If the target did not stop because of a watchpoint, > >> target_stopped_data_address should return zero. Past implementations > >> of watchpoints for remote targets have relied on special registers > >> returned in the 'g' packet to determine the data address. > >> > >> Rather than having gdb deal with the debug support registers directly, > >> I would like to add a remote protocol packet that can be used to > >> query the target for this address. > >> > >> Comments? > >> > >> --Mark > > > That really sounds like more of a gdb thing. xxx-tdep.c should have > > the knowledge about the registers, though, not remote.c. > > I'm trying to be consistent. Gdb already supports installing and deleting > hw breakpoints and watchpoints via the Z packet in remote.c. Because the > watchpoint support also needs to get the data address, it seemed right > to do that through a packet in remote.c also. > > I'm OK with putting the work of watchpoint support on the gdb side, its less > work for me on the target side. But if we're going to add knowledge of debug > support registers into gdb, then we might as well do the installing and > removing of watchpoints via that mechanism instead of messing with a Z packet. Oh. Yes, I see what you mean. Just ignore me. J.T. should comment on this. And maybe Fernando -- weren't you involved with the "z" packet, Fernando? >From jtc@redback.com Mon Oct 30 12:39:00 2000 From: jtc@redback.com (J.T. Conklin) To: Mark Salter Cc: gdb-patches@sources.redhat.com Subject: Re: Remote watchpoint support. Date: Mon, 30 Oct 2000 12:39:00 -0000 Message-id: <5mg0leoyg6.fsf@jtc.redback.com> References: <200010301416.e9UEG6m18981@deneb.localdomain> X-SW-Source: 2000-10/msg00279.html Content-length: 2732 >>>>> "Mark" == Mark Salter writes: Mark> I'm adding hw break/watchpoint support to a remote target. I'm using Mark> the Z-packet support that is in remote.c to install/remove the Mark> watchpoints and breakpoints. When a watchpoint is triggered by a Mark> read access, GDB needs a way to tell if the target stopped because Mark> of the watchpoint. This is done through a target specific function: Mark> Mark> CORE_ADDR target_stopped_data_address(void) Makr> Mark> which returns the address of the data access which triggered the Mark> watchpoint. If the target did not stop because of a watchpoint, Mark> target_stopped_data_address should return zero. Past implementations Mark> of watchpoints for remote targets have relied on special registers Mark> returned in the 'g' packet to determine the data address. Mark> Mark> Rather than having gdb deal with the debug support registers directly, Mark> I would like to add a remote protocol packet that can be used to Mark> query the target for this address. I was unware of this macro, yet we've been using hardware watchpoints on a i386 target using the remote protocol for about a year. Now that I've examined the code in breakpoint.c which invokes it, I must assume that no one has tried to use read or access watchpoints. I'm not sure I like the protocol change though. One thing I dislike about it is that the debug agent never explicitly tells GDB that a watchpoint has been hit, but rather it is implicitly coded in the return value of the query. The second is the return value of 0 if the target stopped for another reason. I (now) know that this is the current behavior of the target_ stopped_data_address() macro, but it use the one address that I think might be very important to watch on targets where the zero page isn't unmapped (in which case a reference would cause a exception/trap). While it might not be possible to fix in GDB's internals for some time, preserving it in the remote protocol for all time seems like a mistake. I think the way I'd go about this would be to add additional return codes. In earlier messages, I have mentioned it would be desirable for GDB to represent breakpoints and single steps distinctly from exceptions (e.g., adding a TARGET_WAITKIND_BREAKPOINT and TARGET_ WAITKIND_STEP). I don't know when (or if) we'll ever get around to that, but now that I think about it there is no reason why external protocols could not do so 'ahead' of GDB itself. For the time being, gdb would have to re-multiplex them into an SIGTRAP exception, but it could also extract additional information (such as a watchpoint data address) at the same time. Thoughts? --jtc -- J.T. Conklin RedBack Networks >From fnasser@cygnus.com Mon Oct 30 12:53:00 2000 From: Fernando Nasser To: Larry Smith Cc: gdb-patches@sources.redhat.com, insight@sources.redhat.com Subject: Re: [RFA] 100494 fix Date: Mon, 30 Oct 2000 12:53:00 -0000 Message-id: <39FDDFB0.D995A63E@cygnus.com> References: <200010272126.RAA02584@ozma.smith-house.org> X-SW-Source: 2000-10/msg00280.html Content-length: 2357 Good catch Larry. But please add a labeled frame around the radiobuttons, will you? The target selection dialog expansion box does look weird with two square buttons and two rounds with no explanation. "Run method" sounds right for the frame label. If you really want to fix this, make sure the option is set to "run" and the buttons greyed if the target "exec" is selected. Cheers, Fernando P.S.: Insight patches go to the insight list, not gdb-patches as the people that wrote the code watch it more closely and there is a larger group of users and contributors in this list that do not subscribe to gdb-patches. Larry Smith wrote: > > The following patch is for 100494, changing a pair of checkbuttons > to radiobuttons. Since the proper behaviour was already enforced > this is really only cosmetic, and changes no current control flow. > > I apologise for being unaware of proper protocol for doing patches > on sourceware, this has already been checked in. I will try to be > more circumspect in the future... > > regards, > Larry > > 2000-10-26 Larry Smith > > * change targetselection.itb: Run Program and Continue From Last Stop > are now radio buttons rather than checkbuttons > > Index: targetselection.itb > =================================================================== > RCS file: /cvs/src/src/gdb/gdbtk/library/targetselection.itb,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -r1.4 -r1.5 > --- targetselection.itb 2000/09/12 20:04:11 1.4 > +++ targetselection.itb 2000/10/26 20:47:57 1.5 > @@ -488,11 +488,11 @@ > checkbutton $frame.load -text {Download Program} -variable $var > > set var [pref varname gdb/src/run_cont] > - checkbutton $frame.cont -text {Continue from Last Stop} -variable $var \ > + radiobutton $frame.cont -text {Continue from Last Stop} -value 1 -variable $var \ > -command [code $this set_run run] > > set var [pref varname gdb/src/run_run] > - checkbutton $frame.run -text {Run Program} -variable $var \ > + radiobutton $frame.run -text {Run Program} -value 1 -variable $var \ > -command [code $this set_run cont] > > # The after attaching command entry -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From jtc@redback.com Mon Oct 30 13:03:00 2000 From: jtc@redback.com (J.T. Conklin) To: Michael Snyder Cc: Mark Salter , gdb-patches@sources.redhat.com Subject: Re: Remote watchpoint support. Date: Mon, 30 Oct 2000 13:03:00 -0000 Message-id: <5m66maoxdo.fsf@jtc.redback.com> References: <200010301416.e9UEG6m18981@deneb.localdomain> <39FDCF55.46BD@redhat.com> X-SW-Source: 2000-10/msg00281.html Content-length: 1066 >>>>> "Michael" == Michael Snyder writes: >> Mark Salter wrote: >> I'm adding hw break/watchpoint support to a remote target. I'm using >> the Z-packet support that is in remote.c to install/remove the >> watchpoints and breakpoints. When a watchpoint is triggered by a >> read access, GDB needs a way to tell if the target stopped because >> of the watchpoint. This is done through a target specific function: Michael> That really sounds like more of a gdb thing. xxx-tdep.c Michael> should have the knowledge about the registers, though, not Michael> remote.c. Well, that's one thing that Mark's change has going for it. Like the "Z" packet, the proposed "qWaddr" packet knows nothing about how the target implements hardware break/watchpoints. Those details are left up to the debug agent. While it's probably processor debug registers, it could be an external device that speaks the remote debug protocol and talks to the target over BDM or some other on-chip-debugging tech- nology. --jtc -- J.T. Conklin RedBack Networks >From brolley@redhat.com Mon Oct 30 13:17:00 2000 From: Dave Brolley To: gdb-patches@sources.redhat.com Subject: Patch:RFA:sim testsuite: Options Embedded in Test Cases Date: Mon, 30 Oct 2000 13:17:00 -0000 Message-id: <39FDE57F.A237E2A5@redhat.com> X-SW-Source: 2000-10/msg00282.html Content-length: 760 Hi, The attached patch addresses two issues: 1) Yet another attempt at passing the correct cpu to the assembler when more than one machine is being tested. This time I've defined a global variable 'cpu_option' which the caller can set to indicate the name of the option which specifies the cpu. 2) Resetting options between test cases. Currently options from previous test cases are not cleared and sometimes they leak into subsequent tests. Specifically unsetting them seems to be the only way to make the "if [info exists