Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752955AbbFVPWx (ORCPT ); Mon, 22 Jun 2015 11:22:53 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:64921 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751455AbbFVPWp (ORCPT ); Mon, 22 Jun 2015 11:22:45 -0400 Message-ID: <55882825.3030804@huawei.com> Date: Mon, 22 Jun 2015 23:22:13 +0800 From: Hou Pengyang User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ingo Molnar CC: "Wangnan (F)" , , , , , Subject: Re: [RFC] perf report: introduce --map-anon-mem for anon-executable-memory symbols parsing References: <1434636076-13502-1-git-send-email-houpengyang@huawei.com> <5583E088.6080202@huawei.com> <20150619104214.GA3298@gmail.com> In-Reply-To: <20150619104214.GA3298@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.95.59] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5588283B.0199,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6e7bf00e978d091abb7efc769c9f9554 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1708 Lines: 50 On 2015/6/19 18:42, Ingo Molnar wrote: > > * Wangnan (F) wrote: > >> On 2015/6/18 22:01, Hou Pengyang wrote: >>> This patch introduces a --map-anon-mem argument to perf report to deal >>> with anon-executable-memory symbol parsing. >> >> --map-anon-mem is not a good name. The user defined map area list >> introduced in this patch can be used on not only anon mapping but >> also file mapping. > > Yeah, so quirky options generally suck and only 0.01% of the users will use it. > It's in a way worse than not having this code, because we'll have to maintain it, > but it won't be used. > > Is there a way to auto-detect 'executable anon mappings' (perhaps by generating an > MMAP event with some extra bit set, or a new MMAP event?) so that it's all > seemless? > I think it not difficult to generate such MMAP event, just like : 0 435090424309600 0x3e0 [0x68]: PERF_RECORD_MMAP2 788/788:[0x7f946c0000(0x4000) @ 0x7f946c0000 00:00 0 0]: ---p //anon But for symbol parsing, this is not enough. For such mmap area, perf doesn't know the path of '.so/.o', which is necessarcy for symbol- parsing. So we need to tell perf the relationship between the .so file and the mmap range explicitly. Thanks, Hou > The user should not be required to know about such details! > > Thanks, > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/