X-Authentication-Warning: ieva01.lanet.lv: pavenis owned process doing -bs Date: Tue, 25 May 1999 11:24:24 +0300 (WET) From: Andris Pavenis To: Eli Zaretskii cc: djgpp-workers AT delorie DOT com Subject: Re: gdb 4.18 for DJGPP (alpha) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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