From: pavenis AT lanet DOT lv
Message-ID: <B0000087946@stargate.astr.lu.lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Mon, 24 May 1999 14:38:32 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: gdb 4.18 for DJGPP (alpha)
References: <Pine DOT A41 DOT 4 DOT 05 DOT 9905201327380 DOT 92326-100000 AT ieva01 DOT lanet DOT lv>
In-reply-to: <Pine.SUN.3.91.990524114306.14456C-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.11)
Reply-To: djgpp-workers AT delorie DOT com

On 24 May 99, at 11:43, Eli Zaretskii wrote:

> I checked out the latest dbgcom.c and include/debug/dbgcom.h from CVS
> and built GDB with them.  Unfortunately, the resulting binary doesn't
> work correctly.  In the following fragment from go32-nat.c:
> 
> 	{
> 	  if (a_tss.tss_irqn == sig_map[i].go32_sig)
> 	    {
> #if __DJGPP_MINOR__ < 3
> 	      if ((status->value.sig = sig_map[i].gdb_sig) !=
> 		  TARGET_SIGNAL_TRAP)
> 		status->kind = TARGET_WAITKIND_SIGNALLED;
> #else
>         status->value.sig = sig_map[i].gdb_sig;
>         status->kind = TARGET_WAITKIND_STOPPED;
> #endif
> 	      break;
> 	    }
> 	}
> 
> if I enable the v2.03 part, breakpoints stop working (GDB says the
> program got SIGTRAP instead), and if I enable the v2.02 part, Ctrl-C
> kills the debuggee, like with the old dbgcom.c

Of course. GDB gets TARGET_WAITKIND_SIGNALLED that is 
command to kill debugee. We should have 
TARGET_WAITKIND_STOPPED to avoid that.

About breakpoints:
They seems to work normally  with my binary gdb-4.18. 

> Is there anything else in the library I should update besides dbgcom.c
> and <debug/dbgcom.h>?

No.

> > At least I have successfully debugged debugger part in rhide with itself
> > (with gdb-4.17 not 4.18, but I don't think it's a problem as such
> > possibility is determined by dbgcom.c)
> 
> Maybe, if it's not much of a bother, you could send me your source of
> dbgcom.c and your libdbg.a, so I could verify that I didn't do
> anything stupid when I upgraded dbgcom.c?
> 
> I'm mainly concerned that something has gone wrong when I checked
> dbgcom.c into CVS, and we will release a buggy libdbg.a with v2.03,
> after all the efforts that went into improving the debug support.
> 

As far as I remeber I'm using now version of libdbg.a I built from 
CVS version without changes. But perhaps it's best to recheck.

Andris