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
Precedence: bulk

> 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.