Date:	Thu, 20 May 1999 09:59:02 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp-workers AT delorie DOT com
cc:	Robert Hoehne <robert DOT hoehne AT gmx DOT net>
Subject:	Re: gdb 4.18 for DJGPP (alpha)
In-Reply-To:	<m10k6Zw-0006NpC@galjas.cs.vu.nl>
Message-ID:	<Pine.SUN.3.91.990520094344.22291D-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

I'm trying to remove unnecessary #ifdef __GO32__ in GDB sources, and I 
have bumped into some strange snag.  I'm still investigating this, so the 
info below is admittedly incomplete; I simply want to know if this is a 
known problem and if somebody could give me a hint where to look.

Here's the deal: I enabled signal handling in readline (see 
readline/signals.c in the GDB sources) by removing "#undef HANDLE_SIGNALS"
at the beginning of the file.  Source inspection seems to indicate that 
the code in signals.c doesn't do anything bad or unsupported by DJGPP.  
However, the resulting gdb.exe seems to work well when debugging other 
programs, including if I press Ctrl-C, but crashes when debugging itself.

Specifically, the following sequence of commands leads to a crash:

	gdb gdb.exe
	run
	help info
	Ctrl-C

(I press Ctrl-C after the inferior GDB displays the first screenful of 
the help info and prompts me to press Enter or q.)

The inferior GDB is killed when I press Ctrl-C (which I understand is the 
correct behavior), but then the parent GDB gets SIGSEGV and dies.

The traceback is also strange: the App stack it displays has its limits 
reversed, i.e., in the [addr1..addr2] display addr1 is less than addr2!
(I will post the full traceback later.)

Does this ring a bell for someone?  Is it at all reasonable to expect GDB 
be debugged by itself in a stable manner?  Does v2.02 include known bugs 
in libdbg.a that could produce such problems?

Any help will be most appreciated.

- Raw text -