Date: Wed, 12 Aug 1998 16:58:01 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in>
cc: djgpp-workers AT delorie DOT com
Subject: Re: [grbhat AT unigoa DOT ernet DOT in: Problem with process_coff()]
In-Reply-To: <Pine.LNX.3.91.980812110803.5978A-100000@aditya.unigoa.ernet.in>
Message-ID: <Pine.SUN.3.91.980812164744.366B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 12 Aug 1998, Gurunandan R. Bhat wrote:

> So for any function the loop will stop when it encounters the declaration
> of the next function. For the last function.....?

The natural question here would be: does FSDB crash exactly for such 
cases of ``the last function''?  If it does, then fixing this will
prevent it from crashing; if not, there's one more bug ;-).

> > This assumes that the lines' info for the function being processed is
> > terminated by an entry whose l_lnno member is zero.  
> 
> In the sense described above. The "entry whose l_nno member is zero" is 
> in fact the declaration of the next function. Please confirm this.

Yes, that's what I meant.

> > There's also something else that bothers me.  Earlier, you said that
> > in the case where FSDB crashed, lbase was -1.  This seems like a bug,
> > right there, even before l[i2] is dereferenced: lbase should be a
> > non-negative number, right?
> 
> Only if the function was compiled with -g. If line number info for a 
> module is not available, lbase will always be -1.

Again, the natural question would be: what is the situation with this 
aspect when FSDB crashes for you?  Or does it crash on any kind of 
program, -g or not -g alike?

> However the point that lbase = -1 may be used as 
> a flag to stop processing for line numbers may be the safest way to handle
> this.  In fact I did that and found that fsdb works as expected and no 
> crash happens.

Seems like a good idea to include such a change anyway.  It cannot 
possibly hurt, can it?

> As expected (since this is the symbol whose line number 
> entry is last), mallocs tables get corrupted exactly after process_coff 
> reads this module.

So it seems we need either some method of detecting the last l[] element, 
or just terminate the loop when lbase becomes negative, or both.