X-Authentication-Warning:	ieva01.lanet.lv: pavenis owned process doing -bs
Date:	Tue, 25 May 1999 11:24:24 +0300 (WET)
From:	Andris Pavenis <pavenis AT lanet DOT lv>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: gdb 4.18 for DJGPP (alpha)
In-Reply-To:	<Pine.SUN.3.91.990525105126.24405J-100000@is>
Message-ID:	<Pine.A41.4.05.9905251117230.65400-100000@ieva01.lanet.lv>
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 Tue, 25 May 1999, Eli Zaretskii wrote:

> 
> On Mon, 24 May 1999 pavenis AT lanet DOT lv wrote:
> 
> > It appears that I was wrong. The problem is with hardware assisted 
> > breakpoints (hbreak).
> 
> I didn't try hbreak yet.  I will see whether I can reproduce this
> problem tonight.

????

I was not able to get this problems otherwise. Only with hardware
breakpoints (hbreak). Normal breakpoints (break, tbreak) works Ok for me.
I didn't change anything in CVS version of DJGPP (except buggy .txh file
which doesn't matter)

> 
> > First expression is that translation from interrupt to exception 
> > (src/libc/go32/exceptn.S) fails for SIGTRAP when running under 
> > debugger.
>
> The only change in exceptn.S was that, if it finds SS to be the DS
> alias selector, it puts the normal DS into the stack frame popped on
> return from exception, in effect forcing the stack to use the normal
> DS/SS selector once C code is running again.

I don't think this change is significant. I thought about another problem:
	there is 2 places where exception can be tranlated to signal
	(debuger and debugee) and when we are allowing to hook exceptions
	this is a real problem. We have at least partially solved it,
	but as it appears now - not fully yet.

> I don't know whether this can affect the debug support, but it should
> be easy to take this change out, rebuild GDB and see if the problem
> goes away.  I can send you the diffs (which you will need to apply
> with "patch --reverse"), if you want.
> 
> > I tested earlier binaries I had:
> > 	5th Jaunary binary of gdb-4.17 (at that time there were rather 	
> > 	active work with dbgcom.c by Pierre and me). That binary 
> > 	seems  to get hardware breakpoint as required.
> 
> Did that 4.17 binary use the current libc.a?  If not, perhaps you
> could rebuild that 4.17 binary with the current libraries and see if
> the problem is in GDB changes or in DJGPP changes.
> 

It used 2.02 and I only replaced needed modules (such as dbgcom.c).
Perhaps I should run gdb under debugger to see what is different when
we are getting ordinary breakpoint (which works for me) and hardware one
(which doesn't work as expected)

Andris

- Raw text -