This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: BFD for stack trace
- To: binutils at sourceware dot cygnus dot com
- Subject: Re: BFD for stack trace
- From: David Greene <greened at eecs dot umich dot edu>
- Date: Wed, 12 Apr 2000 12:40:24 -0500 (EST)
- Reply-To: greened at eecs dot umich dot edu
On 12 Apr 2000, Ian Lance Taylor wrote:
> 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.
Blech. Overkill for me, I think.
> 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.
Ok, great! BTW, where is the latest documentation for BFD? The only
thing I've ever been able to find are a couple of web pages that look
woefully out of date.
> 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.
Ok, it will do for now.
Thank you!
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know how big he was." -- James P. Johnson