proposed fix for PR 114

[Doug Evans]

Ben Elliston writes:
 > PR 114 relates to gprof --line taking a long time.  The problem is
 > that gprof is stupid about generating the "line table" -- the list of
 > source lines in the program and their address.  It does it by calling
 > bfd_find_nearest_line(), over the full range of valid text addresses,
 > asking "Are you my daddy?"  :-)
 > 
 > I've prototyped a fix which slightly alters BFD's interface, adding a
 > bfd_vma* parameter to bfd_find_nearest_line that returns the address
 > of the next source line (where possible; otherwise it returns the
 > requested address).  This allows us to skip through a large percentage
 > of the program text and reducing the call overhead.  My experiments
 > show a ~40x speedup on the "blastall" program submitted by the PR
 > originator.
 > 
 > This seems to have one flaw, however.  Sometimes, due to instruction
 > reordering at higher optimisation levels, a source line B can begin at
 > an address that lies between the start and end of source line A.  With
 > my patch, that source line will not appear in the profile output.  I'm
 > not quite sure how to handle this, nor am I sure if this would be
 > considered catastrophic.
 > 
 > Comments?

What if instead bfd provided a facility to return in an
application independent (*) fashion the entire line number
table for a given address range?
Then let the app use the data as it sees fit (including
post-processing the data for its own optimal use).

Such a facility might have general use far beyond just gprof.

(*) and debug format independent