Re: [RFA] Fix a crash in coffread.c (Was: GDB 6.1 branch 2004-02-26-gmt)

["Eli Zaretskii" <eliz at elta dot co dot il>]

> From: Elena Zannoni <ezannoni@redhat.com>
> Date: Mon, 23 Feb 2004 10:09:09 -0500
> 
> > +  /* If the line number is full (e.g. 64K lines in COFF debug info),
>                     ^^^^^^^^
>                      table?

Yes, a typo.  Thanks for catching it.

> how about a while loop?

Consider it done.

> I am not sure I understand how the two cases differ in the layout of
> the debug info.

Sorry, I don't understand: what two cases?

> Is the beginning of a function still zero valued?

AFAIU, the code tested for the zero-valued L_LNNO32 (&lptr) too late:
the call to bfd_coff_swap_lineno_in is before the test, and it's that
call that caused GDB to crash, since rawptr ran out of the valid
address space.

> Do we have a function with >64k lines?

No, the entire program totals more than 64k lines.

> If we are running beyond the end of the table, does this mean that
> we don't read all the debug info we have?

We do read all the available info.  GNU ld stops writing the table
when it has more than 64k lines (and prints a warning to that effect).
In the cases I debugged, the line table was allocated for precisely
64k lines, a clear sign that the table overflowed during linking (I
also saw the warning).  Since no more info about line numbers is
available, we don't lose anything.  AFAIK, the rest of the debug info,
i.e. the symbol table, is still being read, we just lose information
about source line to code association for some of the functions.

The reason for running beyond the end of the table is, AFAIU, that the
test to terminate the loop is not good enough to catch the end of the
table in time, at least in the case I debugged.  I don't really
understand how it was supposed to make sure that dereferencing rawptr
in libbfd.c:bfd_getl32 (called from bfd_coff_swap_lineno_in) will not
segfault, without an explicit test of rawptr's value; do you?