Date:	Wed, 21 Mar 2001 19:06:59 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	djgpp-workers AT delorie DOT com
Message-Id:	<2950-Wed21Mar2001190658+0200-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
In-reply-to:	<7458-Sun18Mar2001181340+0200-eliz@is.elta.co.il>
Subject:	Re: Handle executables with more than 0xffff line entries in SYMIFY
References:	<7458-Sun18Mar2001181340+0200-eliz AT is DOT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Sun, 18 Mar 2001 18:13:41 +0200
> From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
> 
> SYMIFY crashes and burns (or prints garbled symbol names) if you run
> it on a program that overflows the COFF 64K limit on line number
> entries in the debug info.  (GDB is an example of such a program.)
> 
> The bug is actually in syms.c, which doesn't guard itself against
> this, and starts poking other data structures when the offset into the
> string table becomes greater than 0xffff.  (Thank God for watchpoints
> in GDB, otherwise I could have no hope to ever find this bug!)  So
> this affects edebug32 and fsdb as well.
> 
> The following changes make SYMIFY cope gracefully with this problem.
> While at that, I also changed symify.c to print "??" instead of a zero
> when the line number info for a call frame is not found, due to this
> overflow.

Since no one objected, I committed these changes.

- Raw text -