libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Konstantin Belousov
Subject: Re: [Libunwind-devel] [PATCH 1/2] ptrace: cache mechanism for /proc/$pid/maps
Date: Tue, 19 Nov 2013 10:16:40 +0200
User-agent: Mutt/1.5.22 (2013-10-16)

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.

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.

Attachment: pgp_2F8OGIBtL.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]