Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751798AbcDZJBA (ORCPT ); Tue, 26 Apr 2016 05:01:00 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:38249 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751516AbcDZJA5 (ORCPT ); Tue, 26 Apr 2016 05:00:57 -0400 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: ravi.bangoria@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Subject: Re: [RFC] perf probe: Fix offline module name missmatch issue To: Masami Hiramatsu References: <1461580708-15169-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com> <20160426062438.aea663884cf5bd95f766f2d5@kernel.org> <20160426111916.50d03e047aaed8112b235686@kernel.org> Cc: linux-kernel@vger.kernel.org, acme@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, masami.hiramatsu.pt@hitachi.com, wangnan0@huawei.com, namhyung@kernel.org, srikar@linux.vnet.ibm.com, naveen.n.rao@linux.vnet.ibm.com From: Ravi Bangoria Message-ID: <571F2E3D.1010303@linux.vnet.ibm.com> Date: Tue, 26 Apr 2016 14:30:45 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160426111916.50d03e047aaed8112b235686@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16042609-8236-0000-0000-000029A501DC Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 939 Lines: 25 Thanks Masami, On Tuesday 26 April 2016 07:49 AM, Masami Hiramatsu wrote: > On Tue, 26 Apr 2016 06:24:38 +0900 > Masami Hiramatsu wrote: >>> +/* >>> + * NOTE: >>> + * '.gnu.linkonce.this_module' section of kernel module elf directly >>> + * maps to 'struct module' from linux/module.h. This section contains >>> + * actual module name which will be used by kernel after loading it. >>> + * But, we cannot use 'struct module' here since linux/module.h is not >>> + * exposed to user-space. Offset of 'name' has remained same from long >>> + * time, so hardcoding it here. >>> + */ > BTW, is there no way to get the module name avoiding to access > this "hidden" data structure? > This looks very tricky way... So this is the same approach kernel use to find module name when module is loaded. Please refer this function for more detail: kernel/module.c :: static struct module *setup_load_info(...) Regards, Ravi