Mail Archives: djgpp-workers/1998/08/12/09:59:56
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.
- Raw text -