Date:	Wed, 5 Aug 1998 13:17:01 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in>
cc:	djgpp AT delorie DOT com
Subject:	Re: fsdb crashes post emacs
In-Reply-To:	<Pine.LNX.3.91.980804190202.2082A-100000@aditya.unigoa.ernet.in>
Message-ID:	<Pine.SUN.3.91.980805130858.11953B-100000@is>
MIME-Version:	1.0

On Tue, 4 Aug 1998, Gurunandan R. Bhat wrote:

> Since I know which memory address is being changed (decremented in this 
> case), I would like to know if gdb can be instructed to stop if the 
> contents of a particular address change, which might help me to 
> understand better the exact location at which the array overstepped.

You need to set a data breakpoint, which will fire when a certain address 
is overwritten.  GDB has a `watch' command which does just that.  
Unfortunately, I have never been able to get it to work (did anybody?).

The ``data-write breakpoint'' feature of FSDB *does* work.  So you might 
try using it to set such a breakpoint at the offending address.  When the 
breakpoint fires, you will see which code accessed that address and can 
then debug as usual.

I will look into the rest of the details you've posted and try to see 
what can I find there.

> Also, I would be grateful to know, if the code in process_coff is 
> particularly affected by the subtle problems of debugging a debugger, 
> something I know very little about.

It shouldn't be.  You might only have problems if you let the debugged 
program (the one loaded by the debugged FSDB) trigger an exception.  At 
that point, the exception will probably be caught by the debugger that 
you use to debug FSDB, rather than by the debugged FSDB itself.  This 
could make the ``outer'' debugger utterly confused.

But if you are careful not to let the ``innermost'' program run, you 
should be safe.

- Raw text -