Date: Thu, 20 May 1999 09:59:02 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: djgpp-workers AT delorie DOT com cc: Robert Hoehne 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 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.