This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
proposed fix for PR 114
- From: Doug Evans <dje at transmeta dot com>
- To: Ben Elliston <bje at au1 dot ibm dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Tue, 25 May 2004 23:43:31 -0700 (PDT)
- Subject: proposed fix for PR 114
- References: <87wu2zsolr.fsf@au.ibm.com>
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