[RFA] Fix a crash in coffread.c (Was: GDB 6.1 branch 2004-02-26-gmt)
Elena Zannoni
ezannoni@redhat.com
Mon Feb 23 21:01:00 GMT 2004
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
More information about the Gdb-patches
mailing list