Date:	Thu, 27 May 1999 10:24:15 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	pavenis AT lanet DOT lv, Robert Hoehne <robert DOT hoehne AT gmx DOT net>,
	djgpp-workers AT delorie DOT com
Subject:	Re: gdb 4.18 for DJGPP (alpha)
In-Reply-To:	<Pine.SUN.3.91.990526073713.20715A-100000@is>
Message-ID:	<Pine.SUN.3.91.990527102328.9561A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 26 May 1999, I wrote:

> Watchpoints still don't work, at least sometimes, but that is the case 
> with Robert's binary (and with GDB 4.16) as well.

It turns out I was wrong.  First, the watchpoints in v4.18 do work
better than in 4.16 (I found several cases where the former reported a
hit while the latter didn't).  And second, in all the cases I've seen
where GDB 4.18 didn't catch the data access, it was because the
variable was in a register (I debugged an application compiled with
-O2).

I find the following a useful trick when debugging optimized code.  If
you want to be sure GDB will catch data accesses to a variable `foo',
try "watch &foo" first; if the variable is in a register, GDB will
complain loudly, and you will know you can't watch that variable.

Btw, FSDB (which I used until now whenever I needed to catch data
accesses) simply refuses to put a data breakpoint on register
variables--you simply cannot get to those variables in FSDB because
specifying their names in the Where-is pane yields nothing.

- Raw text -