Re: watchpoints inside 'commands'

[Edward Peschko <edwardp at excitehome dot net>]

> Ah, okay, then how about setting a breakpoint near the exit from the
> scope where the watchpoint is defined, and setting up the commands of
> that breakpoint to silently delete the watchpoint and continue?  Would
> that do what you want?

Ok, but there is no command - as far as I can tell - to 'silently delete the 
watchpoint and continue'. Take the following code:

---
#include <stdio.h>

void a();

int main()
{
	int xx;
	for (xx = 0; xx < 100; xx++)
	{
		function();
	}
}

int yy = 0;

void a()
{

	char data[10]  = "hello";
	if (yy++%10 == 0) 
		data[0] = 'i';

	
}

if you say something like:

b 20
Breakpoint 1 at 0x10924: file a.c, line 20.
commands 1
> silent
> watch data[0];
> continue

then, gdb will set up a watchpoint (which I assume is a breakpoint) at 20 when 
line #20 is hit. So far so good.

But the watchpoint has a different *number* each time it comes up (ie: watch
data[0] is 'watchpoint 2' on the first way round, watch data[0] is 'watchpoint
3' the second time round, etc. etc.

So this does not work. And in any case, wouldn't it be easier to say -

watch data[0] 22 25

meaning 'watch the memory space represented by data[0] from line 22 to line 25'?

Ed

> Can you get the trashing if some of the threads don't run?  It's
> probably best to have the minimum number of threads that still
> reproduce the problem.

If we turn down the threads, its pretty stable (ie: it still takes time to 
crash, but a longer period) And it does not crash if we take threading out
completely.

> Anyway, how many possible memory regions did you find to be trashed
> until now?  If it is a relatively small number, watchpoints could
> still help (you could watch all or most of them).

its different every time.

> That's true, but you could handle this with watchpoint commands: they
> could simply print their usual stuff and then continue.  Later you
> could examine the session script and decide which of the breaks were
> false alarms and which not.

That would be fine, if watchpoints didn't change their number each time you 
created and deleted them...

> What you describe sounds like uninitialized pointer somewhere, or some
> other source of random addresses being poked.  (Are the regions that
> get trashed really random, or do you have only a small set of possible
> victims?)  If the address is really random, I'd suggest to think what
> could be the source of such randomness.  A random address is not easy
> to get by in most programs.

which is why I think the interface into gcc should change to accomodate this.
Its hell to track down problems like this in program right now, it wouldn't be
(as much hell) if we had an interface like this.

Ed