On Thu, Jan 12, 2012 at 12:58 AM, Harald Servat <[email protected]> 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? _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
