Re: BFD for stack trace

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Wed, 12 Apr 2000 12:27:38 -0500 (EST)
   From: David Greene <greened@eecs.umich.edu>

   Then how does gdb get its information?  I know this is not the gdb 
   list, but if anyone could comment, it would be helpful.

Basically, gdb reads and interprets the debugging information itself.
For object file formats which store debugging information in the
symbol table, gdb uses the BFD asymbol structures.  For object file
formats which store debugging information in sections, gdb uses
bfd_get_section_contents.  Either way, gdb does all the parsing.

   >    1. Read in the object file and get the address range
   >       for every function - where it starts and ends.
   > 
   > I suppose the only way to do this using BFD is to call
   > bfd_find_nearest_line on each address.  You will be safe enough if you
   > increment the address by four each time.  You can save time by
   > skipping ahead by bigger numbers; if you are still in the same
   > function, you are OK, otherwise you have to go back and find out where
   > the function changes.

   Ok, but bfd_find_nearest_line is not documented.  What's the interface?
   What does it return?

boolean
bfd_find_nearest_line (
     bfd *abfd,
     asection *section,
     asymbol **symbols,
     bfd_vma offset,
     const char **filename_ptr,
     const char **functionname_ptr,
     unsigned int *line_ptr)

ABFD is a bfd.  SECTION is a section within ABFD.  SYMBOLS is the list
of symbols of ABFD, as returned by bfd_canonicalize_symtab.  OFFSET is
the offset within SECTION of the address which you want information
about.  If bfd_find_nearest_line returns false, it could not get any
information.  If it returns true, it will set one or more of the
locations pointed to by FILENAME_PTR, FUNCTIONNAME_PTR, and LINE_PTR.
*FILENAME_PTR will hold the name of the source file; if this could not
be determined, it will be NULL.  *FUNCTIONNAME_PTR will hold the name
of the source function; if this could not be determined, it will be
NULL.  *LINE_PTR will hold the line number; if this could not be
determined, it will be zero.

   > When using ELF, you can generally read the symbol table and look for
   > BSF_FUNCTION symbols.  This won't be quite right if you have constant
   > data in the .text section, but when using ELF constant data is usually
   > put in the .rodata section anyhow.

   But AFAIK, the symbols (asymbol) only contain the starting address,
   not the end.  I've been fudging things by sorting the symbols and
   assuming functions appear in the text segment right after each other.
   It seems to work weel enough for what I need, but it's ugly.

Yes.  That symbol ordering is a safe assumption when constant data
does not appear in the .text section.

Ian