Received: by 10.223.185.116 with SMTP id b49csp4509977wrg; Tue, 6 Mar 2018 17:52:56 -0800 (PST) X-Google-Smtp-Source: AG47ELuz6ibTnysvYKbnkseiSbj7o+MoJLkpsBpSo/cWwCiPaABk61Z6RNG4yTAqsZIMVPVkDp7B X-Received: by 10.99.165.9 with SMTP id n9mr16839549pgf.324.1520387576541; Tue, 06 Mar 2018 17:52:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520387576; cv=none; d=google.com; s=arc-20160816; b=i/+Ut7611elsYL5VAsZFxJy0lBaGqNusjCEMoHA4QNb/k5NMb9c1HpqjtJKPH9kVBj l9+kMGrzTT1MHIOPPESC34+SI1cfLmwTmOFB6klXSO59MSADGSji5tFb0fjV4bo8ijis fJO2i031N/rzJPY+hD5XISufIMtCUBQemX6kcaOktsEo4e99wzSnyNNHw+PIVlQS8x3Y deyeVPXioA6PdKyNX9ywmkMKKo8JwaMW6zE2enU7VHi+5a8fEXuGruLkj7n6MKBXR7C3 //LeBpiaIkpTABXtMdY72CdM7ZTX8Wk3SgGExdeic54AB0BLFgekmiYT2BnlhsjU2cBt 2l+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=2YSqV40t+qwjQGY7QefcBtHJVAC0cZvtIvI1T4QavKQ=; b=ZbsNb8oOz1aKHEhpnOAC2xGP/wi0twv6uVGAf6cNIpL0Qgk3nbcVdZlj4AS224IXP6 JwslVcfvLwVuwZj/obzqmJDjnBeSn5DCI5XGN5b4iRMNswpWcV69ba6qu/pFurq0uaYn mPB6aGNavDyPtyijGnYaMift1VopNbslQuJC0GMaT1VCu/TYjconx5E7aHIkbolAKagt yOUcuJhmLaix42+VEny5qPi3Cgqc9YGB3fpk5ZwdGOSzkdncH0trT4ORRo3TxTJkjCxg TPP6jTZDaPzzlt7KImf9MI5yvMog3n7eJh7nyf/De5pPTpEt+t83HYOqQSdbdhN3xkuW oqVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q3si10670923pgp.632.2018.03.06.17.52.05; Tue, 06 Mar 2018 17:52:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753996AbeCGBug (ORCPT + 99 others); Tue, 6 Mar 2018 20:50:36 -0500 Received: from exmail.andestech.com ([59.124.169.137]:10727 "EHLO ATCSQR.andestech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753525AbeCGBuf (ORCPT ); Tue, 6 Mar 2018 20:50:35 -0500 Received: from mail.andestech.com (atcpcs16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id w271lJIp022774; Wed, 7 Mar 2018 09:47:19 +0800 (GMT-8) (envelope-from alankao@andestech.com) Received: from andestech.com (10.0.1.85) by ATCPCS16.andestech.com (10.0.1.222) with Microsoft SMTP Server id 14.3.123.3; Wed, 7 Mar 2018 09:50:17 +0800 Date: Wed, 7 Mar 2018 09:47:47 +0800 From: Alan Kao To: Steven Rostedt CC: Palmer Dabbelt , Albert Ou , "sw-dev@groups.riscv.org" , "linux-kernel@vger.kernel.org" , "Greentime Ying-Han =?utf-8?B?SHUo6IOh6Iux5ryiKQ==?=" , "Zong Zong-Xian =?utf-8?B?TGko5p2O5a6X5oayKQ==?=" Subject: Re: ftrace: Proposal for an Alternative RecordMcount framework Message-ID: <20180307014746.GA25460@andestech.com> References: <20180227100425.GB20904@andestech.com> <20180227161252.25162d81@vmware.local.home> <20180301020507.GA24550@andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20180301020507.GA24550@andestech.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.0.1.85] X-DNSRBL: X-MAIL: ATCSQR.andestech.com w271lJIp022774 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 01, 2018 at 10:05:07AM +0800, Alan Kao wrote: > On Wed, Feb 28, 2018 at 05:12:52AM +0800, Steven Rostedt wrote: > > On Tue, 27 Feb 2018 18:04:26 +0800 > > Alan Kao wrote: > > > > > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2] > > > > Note, doing it at that stage takes the longest time. It makes small > > changes much longer to compile. That said... > > > > What if we can have some option to *disable* all the recordmcount.pl lauches > after every .o? There will be only an oneshot grep for a near-complete > vmlinux binary. > > > > 2. Form the output as an ELF objecj > > > 3. Link the object to __mcount_loc_start symbol > > > 4. Done > > > > > > With the similar reason as the patch [3], we should mark _mcount to be > > > a weak symbol to prevent it from being relaxed later. > > > > > > We would like to know your opinion and comments on this. > > > Thanks! > > > > What about just having your arch use recordmcount.c instead? It doesn't > > do any grepping. It is an elf reader and modifier and modifies the .o > > file directly. > > Thanks for the hint. But after a quick scan, it seems that recordmcount.c > processes .o files in a per-file basis, which means that we will still > suffer from the linker relaxation problem. > > > > > Note, I will be rewriting that code in the near future too, to > > consolidate it with objtool. > > > > -- Steve > > Please allow me to state the problem more clearly here. I hope this helps. > > 1. locations of mcount are recorded in a per-file basis. > 2. to optimize the binary, the linker turns on some aggressive > options, including relaxation. > 3. the optimizations changes the original offset. > 4. already recorded mcount call-sites no longer point to their > real positions. > 5. still a linked vmlinux is made. > 6. dynamic ftrace breaks the real logic in the kernel space, > panics happen. > > Thanks, > Alan Any comments on this? BTW, the introduced framework has no effects on any other architectures that works fine. This feature should be configurable and turned on only when the arch has aggressive link-time optimizations. If you consider this appropriate, I will send the patch to this once it gets ready. Currently this is targeting at RISC-V and upcoming NDS32. Thanks, Alan