This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: using bfd, help please I am confused
- From: Robert Schweikert <Robert dot Schweikert at abaqus dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: binutils at sources dot redhat dot com,Robert Schweikert <rjschwei at abaqus dot com>
- Date: 20 Jun 2003 16:36:57 -0400
- Subject: Re: using bfd, help please I am confused
- Organization: ABAQUS
- References: <1056131220.24077.211.camel@cheetah.hks.com> <m37k7geiav.fsf@gossamer.airs.com>
Ian,
Thanks for the help. I do want to get the information from within the
code, thus I do not want to call addr2line. I have this working if I
have a monolithic executable, but how do I get this to work with shared
libraries?
At this point I am assuming that I only know the name of the executable,
since I don't know whether or not there is a way to figure out the
library name from which the function that is currently on the stack came
from.
Thanks,
Robert
On Fri, 2003-06-20 at 14:05, Ian Lance Taylor wrote:
> Robert Schweikert <Robert.Schweikert@abaqus.com> writes:
>
> > My assumption is that I can somehow figure out the address of the
> > function I am in, from here I'd like to figure out the function name.
> > The approach is to use the
> >
> > void * __builtin_return_address (unsigned int level)
> >
> > kernel function to get the return address of the stack from there I
> > should be able to figure out the function/method name/symbol.
>
> That's a gcc builtin function, not a kernel function.
>
> If you pass the address you get to addr2line, you should find the
> function name, etc. Here's the documentation for addr2line:
> http://sources.redhat.com/binutils/docs-2.12/binutils.info/addr2line.html#addr2line
>
> If you want to get that information from within the program, without
> using an external program, then you are going to have to link your
> program against libbfd and call bfd_find_nearest_line(). Look at the
> sources to addr2line for some hints.
>
> Ian
--
Robert Schweikert <Robert.Schweikert@abaqus.com>
ABAQUS