Received: by 10.223.185.116 with SMTP id b49csp4764558wrg; Tue, 27 Feb 2018 02:08:30 -0800 (PST) X-Google-Smtp-Source: AH8x226QuGf/nNBdZCWrgu60NsKIPiJ8pfJpvjMCncg8V0SJDsvuhxuPYHYX6NHfz78hGiZomML6 X-Received: by 2002:a17:902:7c87:: with SMTP id y7-v6mr13854179pll.112.1519726110622; Tue, 27 Feb 2018 02:08:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519726110; cv=none; d=google.com; s=arc-20160816; b=ev9ZIY5hoSzQxh6Eldi0DDZEbQAwC19PmoZyb4jo++gQv9+7erSRm8ujFn1tEZeHRe UkEOF52zqMQ6pTfquRDVMaPzZQaJ0remmktQRWaYJaopgqq5LwrF2yeRCUyQ8rsiLN7D 5l4xihBHdd/T3bbg+VdU9nYXEj+Mq5JcVxAleV8CMHt8rmktwrMRotN804DU21JPLJqC B0soyfNLuDGKQ5GGlKju36TmLCCyS07+72w52Qyv36RsP0tLa+v1ra9N0fIny2QAFwHG MjhMLrAmE17NQ1CrVnVU2zpsfDL/1TtE7r/onF+MsagoqQVv6tnnqQH6mpaNpcqt7X/t +1Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date :arc-authentication-results; bh=cR6Te3XMVo/L8NRXnbsYcqsuwp8SlJ7elCTLvCK1DMc=; b=VQr/AZ9xSO3Y4RM/cmUVEHZANI4QwDVGcf6jpVl5MSAK6aPrpK+GxoJPfu5+zbki1l R8QsHen0ai3gIbNuhd89bR6h3IjyG47izO8FURQ56tefCMv7l2azpS99D3SMAHle/3Oc RZU4r3RFljxxVB03WkhT/dDjhF5MisDfW/mMP/vjMbhFhO6+4LAUdjUCaIOySjQz6YCn Vm7eVEr42ibkOq0PPknFOGRsLf69g4AVMc6L7rEM8jbYq0azghTHfgkmJlZOtM72ZGgE 9EimwX8wr8X59EkrKZ+atCCy2/8/M8Yp5wtNIZf8+5NYQWEFLyZ/xMJfp91TD2m8p84x ZzxQ== 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 v3-v6si8314230plg.575.2018.02.27.02.08.16; Tue, 27 Feb 2018 02:08:30 -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 S1752610AbeB0KHh (ORCPT + 99 others); Tue, 27 Feb 2018 05:07:37 -0500 Received: from exmail.andestech.com ([59.124.169.137]:59815 "EHLO ATCSQR.andestech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751998AbeB0KHd (ORCPT ); Tue, 27 Feb 2018 05:07:33 -0500 Received: from mail.andestech.com (atcpcs16.andestech.com [10.0.1.222]) by ATCSQR.andestech.com with ESMTP id w1RA4qfS073557; Tue, 27 Feb 2018 18:04:52 +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; Tue, 27 Feb 2018 18:07:13 +0800 Date: Tue, 27 Feb 2018 18:04:26 +0800 From: Alan Kao To: Steven Rostedt , Palmer Dabbelt , Albert Ou , , CC: , Subject: ftrace: Proposal for an Alternative RecordMcount framework Message-ID: <20180227100425.GB20904@andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.0.1.85] X-DNSRBL: X-MAIL: ATCSQR.andestech.com w1RA4qfS073557 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Steven, Current recordmcount framework collects the mcount call-sites by grep'ing the relocation info in each *.o file right after it is compiled, and then puts them into the __mcount_loc_start array. This works fine in many architectures, but as mentioned in this riscv/ftrace patch[1], aggressive relaxing optimizations corrupt the collected offsets, resulting in panics due to wrong call-site patching in runtime. Meanwhile, some architectures, such as RISC-V and the on-going nds32, highly rely on linker relaxation as a link-time optimization to reduce code size and improve performance. It would be very undesirable to sacrifice them for ftrace only. But, why can't we collect the call-sites after all of them are fixed? We propose an alternative framework, for architectures that cannot properly record call-sites because of relaxing. Here is the rough procedure: 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2] 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! Alan Kao [1] riscv/ftrace dynamic support [patch v4 1/6]: https://lkml.org/lkml/2018/2/13/12 [2] This used to not collect some call-sites since their jumps has no target symbol hint. It becomes possible after the fix in 2.30 release. See https://github.com/riscv/riscv-binutils-gdb/issues/129 for more details. [3] https://lkml.org/lkml/2016/5/14/101