RE: [RFC] Add watchpoint hit address function to procfs.c

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

> See here for a workaround that requires no testsuite changes:
>  <http://sourceware.org/ml/gdb-patches/2010-04/msg00544.html>

  Yes, but that one requires root privileges...
I will try to resubmit my lib/gdb.exp patch shortly...
 
> >   So there are no regressions.
> 
> Thanks.
> 
> > Remaining failures are:
> > pierre@fpcOpenSolaris:~/gdbcvs/build64/gdb/testsuite$ grep FAIL
> gdbv4.sum
> > FAIL: gdb.base/watch-read.exp: read watchpoint triggers when value
> doesn't change, trapping reads and writes
> > FAIL: gdb.base/watch-read.exp: only read watchpoint triggers when
> value doesn't change
> 
> Odd.  I don't suppose a procfs client is supposed to
> handle overlapping watchpoints instead of having the kernel
> handle them?  The test explicitly sets a write watchpoint watching
> the same memory as a read watchpoint, and expects reads to still
> be trapped.  Maybe the write request overwrote the read
> request?  Maybe this is a kernel bug?
No idea here, the log inspection clearly confirms that
the read watch after watch insertion is missed.

> > KFAIL: gdb.threads/watchthreads2.exp: gdb can drop watchpoints in
> > multithreaded
> > app (PRMS: gdb/10116)
> > FAIL: gdb.threads/watchthreads.exp: threaded watch loop
> > FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit
> > FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit
> > FAIL: gdb.threads/watchthreads.exp: watchpoint on args[0] hit in
> thread
> > FAIL: gdb.threads/watchthreads.exp: watchpoint on args[1] hit in
> thread
> > FAIL: gdb.threads/watchthreads.exp: combination of threaded
> watchpoints = 30

  Those failure are a problem within the watchthreads.exp
source, the test uses '\r' patterns without the '\n' as is usual...
If I replace all '\r' by '\r+' then there are no failures left
for that test.
  I ran again both versions (with TIDGET or plain zero)
and got exactly the same output for both. Thus, apparently the 
thread number is not necessary to get the location of the
watchpoint even if it is not in the main thread (for my OpenSolaris version
at least...)
  
  
  It is rather unusual to use \r patterns alone inside the 
GDB testsuite...

   The following patch fixes the failures shown here,
is this patch OK, or should I replace all '\r' into '\r\n'
(in that case, my lib/gdb.exp patch would catch it...)

Pierre

testsuite ChangeLog entry:
 
2010-05-10  Pierre Muller  <muller@ics.u-strasbg.fr>

	* gdb.threads/watchthreads.exp: Allow multiple `\r' in
	regular expression pattern to avoid problems with systems
	uses `Dos-like' newlines.

Index: watchthreads.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/watchthreads.exp,v
retrieving revision 1.11
diff -u -p -r1.11 watchthreads.exp
--- watchthreads.exp    5 May 2010 18:07:03 -0000       1.11
+++ watchthreads.exp    10 May 2010 21:12:44 -0000
@@ -79,11 +79,11 @@ for {set i 0} {$i < 30} {incr i} {
        # At least one hardware watchpoint was hit.  Check if both were.
        set string $expect_out(1,string)

-       if [regexp "Hardware watchpoint 2:
args\\\[0\\\]\[^\r\]*\r\[^\r\]*\r\[^\r\]*Old value =
$args_0\[^\r\]*\r\[^\r\]*New value = [expr $args_0+1]\r" $string] {
+       if [regexp "Hardware watchpoint 2:
args\\\[0\\\]\[^\r\]*\r+\[^\r\]*\r+\[^\r\]*Old value =
$args_0\[^\r\]*\r+\[^\r\]*New value = [expr $args_0+1]\r+" $string] {
            incr args_0
            incr test_flag_0
        }
-       if [regexp "Hardware watchpoint 3:
args\\\[1\\\]\[^\r\]*\r\[^\r\]*\r\[^\r\]*Old value =
$args_1\[^\r\]*\r\[^\r\]*New value = [expr $args_1+1]\r" $string] {
+       if [regexp "Hardware watchpoint 3:
args\\\[1\\\]\[^\r\]*\r+\[^\r\]*\r+\[^\r\]*Old value =
$args_1\[^\r\]*\r+\[^\r\]*New value = [expr $args_1+1]\r+" $string] {
            incr args_1
            incr test_flag_1
        }