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

[Elena Zannoni <ezannoni at redhat dot com>]

Eli Zaretskii writes:
 > > 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?

with and w/o the max reached. You explain below.

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

ah, right.

 > > Do we have a function with >64k lines?
 > 
 > No, the entire program totals more than 64k lines.
 > 

ok, I am not too familiar with the layout. I guess there is a big
table with 0 entries to mark functions.

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

ah, ok. I was wondering at what stage the information was lost. We
don't have to worry about it then.

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

No, probably it was one of those "it will never happen" things. I've
seen those assumptions before...

Ok, then, check it in.

elena