Joel, you said this patch caused you some problems, and asked me to
put it on hold until you had more data.  Can you verify that this does
indeed break something?  I'm pretty confident that you were observing
something else.

I'm skeptical that it causes problems because the patch (as I
understand it, anyway) simply prevents GDB from reading data it will
never use.  The logic goes like this:

If num_symbols > 0, then GDB behaves exactly as before.  This is easy
to see.

If num_symbols is zero, then:
a) GDB does not call bfd_map_over_sections with find_linenos as its
   working function.  find_linenos's only side effect is to set
   info->{min,max}_lineno_offset.  So those are left zero.
b) We don't register free_linetab_cleanup.
c) We don't call init_lineno.  That function's only side effect is to
   set linetab{,_offset,_size}.  Since this is the only place the
   table is ever allocated, b) has no effect.  And this call is the
   only use of info->{min,max}_lineno_offset, so we know that a) has
   no effect.
d) We pass zero as coff_symtab_read's second argument, nsyms.  This is
   just what GDB would do without the patch, so this can't break
   anything new.  But when nsyms is zero, we never enter
   coff_symtab_read's main while loop, so enter_linenos never gets
   called.  That function is the only use of linetab{,_offset,_size},
   so c) has no effect.