This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA]: Modified Watchthreads Patch


Jeff Johnston wrote:
Daniel Jacobowitz wrote:

On Fri, Dec 10, 2004 at 03:02:41PM -0500, Jeff Johnston wrote:

On the technical side, two questions:

1) I can see that it will be a bit of work to rearrange i386-linux to
use this, but it should be doable.  Do you know offhand of any
i386-specific problems other than inserting watchpoints for all
threads?


Actually, with i386/x86-64 I discovered that the debug registers are global in scope for the setting of watchpoints (i.e. I didn't have to use the observer). The status register, however, is thread-specific for reporting them. I have gotten the watchthreads.exp testcase working for both platforms. Your lwp fix helps a lot with this. We call TIDGET()/PIDGET() in the low-level code which used to get called in the wrong ptid mode so we kept checking the main-thread for the watchpoint.



Er... do you know why the debug registers are global, and what kernel
is this with? They look thread-specific to me (kernel 2.6.10-rc1). They are accessible using PEEKUSR/POKEUSR for each thread, and
__switch_to updates them at context switches.



I am simply speaking from experience with the RHEL3 kernel. I got it working without touching the insert/remove logic. I am currently retrofitting new changes into the mainline gdb that are much "cleaner" than my previous fixes. I haven't tried x86 on the latest kernel, but I am in the midst of putting together an uber-patch with the stuff here plus some other things needed for each platform. IA64 is already finished and running watchthreads.exp on a next-release kernel. I am about to start x86 so I will keep in mind your comment. I'll let you know either way what I had to do to get it working.



Interesting results. Applying my previous patch and just changing the FIXME code in dr_get_register and dr_set_register to use the standard:


tid = TIDGET (inferior_ptid);
if (tid == 0)
  tid = PIDGET (inferior_ptid);

allows watchthreads.exp to work for both x86 and x86_64. For x86, I used an fc3 system with a 2.6.9-1.667smp kernel. I had to use an RHEL3 2.4 kernel for x86-64.

The test sets two watchpoints that will be triggered once in the main thread and thereafter in two distinct threads. The test verifies that each value is incremented as it should in the correct thread. It makes sure there are no missing jumps. I have witnessed multiple watchpoint events and thread creation events requiring processing at the same time (i.e. deferred events required) and it handles these correctly.

I tried an experiment and broke in the thread function in one of the threads. I then watched a variable that can only be triggered in a separate thread. That also worked which was cool.

As I observed before, the actual watchpoint only needs to be set on one thread and it will trigger in other threads. I can send you the additional patch if you want to experiment with it. I am still waiting for a machine with the latest RH kernel on it. I'll let you know if that works the same.

-- Jeff J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]