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

[Masatake YAMATO]

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.

> 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