Re: Problem with _bfd_elf_find_nearest_line on ia64

["H . J . Lu" <hjl at valinux dot com>]

On Tue, Feb 06, 2001 at 10:31:11AM +0100, Stephane Carrez wrote:
> Hi!
> 
> >
> >The problem is somewhere else. It turns out _bfd_dwarf2_find_nearest_line may
> >not find the function name. I moved the part of _bfd_elf_find_nearest_line to
> >elf_find_function and used it to find the function name if it is not found
> >by _bfd_dwarf2_find_nearest_line. Any comments?
> >
> >
> 
> If I understand your problem & patch, _bfd_dwarf2_find_nearest_line() returns
> true but does not fill out the function name.
> 
> This is possible if it finds the line number, but not the function name.
> My feeling is that it is possible only if you have some inconsistency
> either between .debug_line/.debug_info sections, or, when these two sections
> are parsed.
> 
> My fear is that your fix is probably hidding a problem in the dwarf2 reader.
> 

See comments from dwarf2.c:

  /* FIXME: There is a problem with the contents of the
     .debug_info section.  The 'low' and 'high' addresses of the
     comp_units are computed by relocs against symbols in the
     .text segment.  We need these addresses in order to determine
     the nearest line number, and so we have to resolve the
     relocs.  There is a similar problem when the .debug_line
     section is processed as well (e.g., there may be relocs
     against the operand of the DW_LNE_set_address operator).

     Unfortunately getting hold of the reloc information is hard... 

     For now, this means that disassembling object files (as
     opposed to fully executables) does not always work as well as 
     we would like.  */

...

              /* DW_AT_low_pc and DW_AT_high_pc are optional for
                 compilation units.  If we don't have them (i.e.,
                 unit->high == 0), we need to consult the line info
                 table to see if a compilation unit contains the given
                 address.  */

The file in question is an object file. So we only get the line number,
not the function name for an object file.


-- 
H.J. Lu (hjl@valinux.com)