This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: patch for binutils bfd/dwarf2.c.
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Nathan Tallent <eraxxon at alumni dot rice dot edu>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 25 Sep 2002 09:36:50 -0400
- Subject: Re: patch for binutils bfd/dwarf2.c.
- References: <002901c26497$b1d54aa0$05c4c943@nesini>
On Wed, Sep 25, 2002 at 09:30:14AM -0400, Nathan Tallent wrote:
> What follows is a patch for binutils bfd/dwarf2.c.
> -Nathan Tallent
>
>
> Description:
> ------------
> lookup_address_in_line_info_table:
> In the case that the function is found but a line number is not for a given
> vma, this routine currently returns the line number and filename of the
> most recently examined vma, if available. (This is supposed to be tailored
> for GCC 2.95.) However, because the list is searched 'backwards', if the
> vma is not found then at the end of the search the most recently examined
> vma will be near the beginning of the function. This behavior can result
> in bogus line number reporting for non-GCC compiled binaries. I have
> changed the function to instead report the filename and linenumber of the
> *nearest* vma in the case that an exact match is not found.
What compiler is producing this bogus information (this case only ever
applies for bogus debug info)? Is there a gap in the middle of the
function without any line number information?
I'd really like to see the debug info you're trying to handle here.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer