RE: Easiest way to get function name/offset from a hex address?
RE: Easiest way to get function name/offset from a hex address?
- Subject: RE: Easiest way to get function name/offset from a hex address?
- From: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Thu, 29 Jan 2009 09:29:22 -0500
- Thread-topic: Easiest way to get function name/offset from a hex address?
Terry Lambert wrote on Wednesday, January 28, 2009 4:37 PM
> On Jan 28, 2009, at 11:15 AM, Karan, Cem (Civ, ARL/CISD) wrote:
> > I'm using -finstrument-functions to figure out what the stream of
> > calls is that causes my program to crash. Since -finstrument-
> > functions instruments everything with calls to
> > __cyg_profile_func_enter() & __cyg_profile_func_enter(), I have the
> > hex address of the function that is being called, and the
> site where
> > it is being called from. I'd like to convert that information to
> > printable strings so I know the name of the function and the offset
> > from the start of the function (or, better yet, the line
> number, but
> > I'll live with the offset). Is there a simple way of doing this
> > lookup? I looked into nlist(), and it appears to have some of the
> > information I need, but I don't see how to get the function
> names from
> > the information it gives me.
> >
> > Any help is appreciated.
> >
>
> Within the program itself:
>
> man dladdr
>
> Outside the program itself:
>
> man atos
>
> The debugger, gdb, also has multiple modes in which it
> operates, two of which can be programmatically controlled (to
> permit things like GUIs that still use gdb internally). You
> could open the binary with gdb in one of these modes and
> interactively query gdb for the information.
Can you tell me what these modes are? Or at least what to look for in
the manual?
> If the intention is from within the instrumentation, dladdr
> will be your best bet.
Funnily enough, that was one of the things I tried. Earlier, I couldn't
get my program to link when I had it in there. Now it linked. I'm
starting to think someone is trying to drive me crazy...
> If the intention is post-mortem analysys, your best bet is
> going to be atos.
>
> If the intention is interactive external analysis (for
> example, if you are recording non-statistical profiling arcs
> in shared memory and analyzing them on the fly), your best
> bet is going to be gdb.
My first choice is GDB, if I can get it to launch GUI apps correctly.
However, for alpha/beta testing, the dladdr trick is probably what I'll
need. Crash reports just don't give enough info on how I got into the
state I'm currently in.
Thanks,
Cem Karan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden