Re: [Libunwind-devel] retrieving symbols

[Steve Fink]

On Thu, Jan 12, 2012 at 12:58 AM, Harald Servat <address@hidden> wrote:
>
> Al 12/01/12 01:30, En/na Steve Fink ha escrit:
>> With the current API, it seems like the only way to map return
>> addresses to symbols is to do it during iteration
>> (unw_get_proc_info(), which takes a cursor.) This is awkward for
>> things like profilers, where you want to quickly capture a bunch of
>> stack traces (probably during a signal handler), and then analyze them
>> later in aggregate. You might, for example, want to eliminate
>> duplicate PCs before looking up symbols. Or only look up symbols for a
>> subset of the stack samples (perhaps you're keeping a circular buffer
>> of samples and only analyzing samples preceding events of interest.)
>
>  I'd like to see something similar. In our current approach, we did
> some coding on top of the libbfd and liberty libraries doing a work
> which would be similar to addr2line -e (all three from binutils). This
> would somewhat "useless" if libunwind can make it.

Yes, that's partly why I'm here now too -- libbfd could do it, but
it's GPL. (Not LGPL.)

>  Also, libbfd & liberty provide information such  routine, file and
> line numbers. What does libunwind provide?

>From what I can tell, only the symbol, offset, and procedure's full
address range. Though there's a pointer to the "unwind-info", whatever
that is, and perhaps that can somehow be used to get more?

It would be really great to get filename:lineno and maybe the filename
of the object file containing the address.

>> How difficult would it be to support address -> symbol lookup without
>> a cursor? (Or is it there, and I'm missing it?) Right now, I'm using
>> dladdr(), which requires linking in a way that I can't really do. And
>> I don't really want to popen addr2line.
>
>  I've read Arun's answer in your other mail. However, I see a drawback
> there in our specific situation. In our case, the binary that generates
> the final tracefile is not the analyzed application but a secondary
> application. Thus we don't have the chance to use unw_set_reg because
> the process image is not the same as the one it was being executed. In
> fact, the analyzed application binary is received as a parameter and
> passed to bfd_open.

Is the analyzed binary still running? Could you use libunwind's remote
interface to access it via ptrace or whatever?