Re: [Libunwind-devel] [PATCH 1/2] ptrace: cache mechanism for /proc/$pid/maps

[Konstantin Belousov]

On Tue, Nov 19, 2013 at 05:29:03PM +0900, Masatake YAMATO wrote:
> Thank you for reviewing.
> 
> On Tue, 19 Nov 2013 10:16:40 +0200, Konstantin Belousov <address@hidden> 
> wrote:
> > On Tue, Nov 19, 2013 at 11:47:11AM +0900, Masatake YAMATO wrote:
> >> I'm working on adding stack trace feature to strace(strace-k).  In
> >> addition to the name of invoked system call, strace-k prints the stack
> >> trace of the process.
> >> 
> >> libunwind is main part of the feature. After some testing I found
> >> `_UPT_get_proc_name' is a performance bottleneck of the fuature. On
> >> linux the function opens and scans /proc/$pid/maps(MAP) for each name
> >> resolving. Generally MAP should be reread for each name resolution
> >> because memory mapping of a process can be altered. However, strace
> >> knows well when the memory mapping of the target process is altered
> >> because strace tracks the invocations of system calls which modify
> >> memory mapping. Therefore rereading is just inefficient for strace.
> > I do not see any os-depended features ised in the map cache implementation
> > you provide, am I mistaken ? If not, I do not understand why this should
> > be linux-specific.
> 
> Can I expect other OS like FreeBSD also provides /proc/$pid/maps?  My
> experience is only about Linux. As far as reading os-freebsd.c,
> FreeBSD provides very different interface to get memory mapping of a
> process.
My point was that, seemingly, your patch does not perform direct operations
on /proc/pid/maps, but caches a return value ?

There is an another patch, submitted in parallel, which also does something
with the process map, now in context of the address validation.  It seems
that we get too many duplicated copies of the map functionality in the
library, so that it makes sense to abstract and provide centralized
os-independed iterators for address space.

> 
> > What I noted is that your cache uses malloc().  Note that both Linux
> > and FreeBSD get_elf_image() avoid non-reentrant calls to allow the
> > backtracing to work from signal handler context, in particular, the
> > memory is allocated by direct mmap(2) use.
> 
> Thank you. I'll resubmit my patch with using mmap.
> 
> Masatake YAMATO

pgpERiYhLjvzO.pgp
Description: PGP signature