Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3634590ybt; Tue, 23 Jun 2020 07:15:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCrqT4kTFUdv/PSYYFMovpeKDpB7OYFhE79DG7BIwmqml2HJob21DLyWQeB9pcHegT5XkX X-Received: by 2002:a17:907:7283:: with SMTP id dt3mr21099092ejc.195.1592921700680; Tue, 23 Jun 2020 07:15:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592921700; cv=none; d=google.com; s=arc-20160816; b=r+lNh/+mKD7kxpOEOewCk3XHGaH81fI2/qszz2c+M26xzBU1nsq6YRWAZLe20FBkJZ e9XHaBKl1x81MVs9iJA0sIIZ8mkRE/hvr3lZ6s4QFPhEeaAQeEXrieVbDWYKhmTY/kfx 4QziS/7nqFEx7AKA9tzHVvjZvMpW3lxwSIXMBm9I3QaKO1cvr3NdLx/EuF23/y46qJsa Pr9qiZlkCdezTLEPmVMPQW7plMrSNplf88pnbZCVAn8KFW+nzepjnWaBaPJxH+zUhb4i oWjLL6jXYONq9RyTHENzjL8BtKvKttzvwgc+bE/EyO+B7k6zHKCyV893+pM6m5IqFLLA zYPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date; bh=roMNx7Ko1Rbht7C4pw3l/N41PuiOdxlQVpHqV4EqrDE=; b=HCf95uFJPpaTsiyACMuhQwfTrF2m5y7263iAQaYxcdcaDsrslxDzvoaZDRhZW/9gEp 35yzOo5m4YBkiY2VE4VzIlAEJwxJMgE7c71ZNv3bvbKIlYs2nWB/oougd9jreOlXJqhw GxLwLbnnkyI65S/3LkleL9n52fpdfCz6VH7LIIFNtykLjraPbgMmllSkcQM/YdcHlweV wnrb0Y+55u7k9XLgXmcn956y6miJGgS8Jn3UuXMjFX/low1SBTvjwa6P2q3HQKZcechq qneMPGTRNDZZWKhmgLyKG2CWpTeNWRYQCJmdScMzn3eHuQ6MGH5DK1od7T0wHGb8qb1z FXbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a13si10210009ejb.241.2020.06.23.07.14.36; Tue, 23 Jun 2020 07:15:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732732AbgFWOMU (ORCPT + 99 others); Tue, 23 Jun 2020 10:12:20 -0400 Received: from ex13-edg-ou-001.vmware.com ([208.91.0.189]:52086 "EHLO EX13-EDG-OU-001.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732657AbgFWOMU (ORCPT ); Tue, 23 Jun 2020 10:12:20 -0400 Received: from sc9-mailhost3.vmware.com (10.113.161.73) by EX13-EDG-OU-001.vmware.com (10.113.208.155) with Microsoft SMTP Server id 15.0.1156.6; Tue, 23 Jun 2020 07:12:17 -0700 Received: from localhost (unknown [10.166.68.167]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id BB9C740880; Tue, 23 Jun 2020 07:12:19 -0700 (PDT) Date: Tue, 23 Jun 2020 07:12:19 -0700 From: Matt Helsley To: CC: Josh Poimboeuf , Peter Zijlstra , Steven Rostedt , Julien Thierry , Kamalesh Babulal Subject: Re: [RFC][PATCH v5 00/51] objtool: Make recordmcount a subcommand Message-ID: <20200623141219.GA5580@rlwimi.vmware.com> Mail-Followup-To: Matt Helsley , linux-kernel@vger.kernel.org, Josh Poimboeuf , Peter Zijlstra , Steven Rostedt , Julien Thierry , Kamalesh Babulal References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Received-SPF: None (EX13-EDG-OU-001.vmware.com: mhelsley@vmware.com does not designate permitted sender hosts) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 18, 2020 at 01:37:46PM -0700, Matt Helsley wrote: > recordmcount has its own ELF wrapper code and could utilize > objtool's ELF code to more-portably handle architecture variations. > This series makes recordmcount a subcommand of objtool. It very > gradually converts recordmcount to become a subcommand of objtool and > then reuses parts of objtool's ELF code. > > recordmcount maps the file in and collects simple information it needs to > append a section to the object file. The only part of the original file it > modifies is the address of new section tables -- interestingly enough this > resembles RCU in that we don't really trim the old tables so > much as unlink them via a critical offset and then rely on > future tooling, in this case, to drop the unused bits. > > Much of the recordmcount ELF code is only reading and walking the data > structures to collect the mcount locations it records in a separate > area of memory. This means it's safe to mix access to the mapped > file with access to the objtool-style linked data > structures as we gradually convert it to using only the linked data > structures. Once the old ELF code is no longer in use we can drop it > and use objtool to take over the task of writing the results without > using the RCU-like trick any more. > > After that we greatly simplify the mcount subcommand by adding a > few flags to the ELF reading code in objtool. Overall the series > removes about 600 lines of recordmcount while adding little to > objtool's ELF code. > > Testing so far: > > I've been using scripts to test cross compilation and execution of > objtool, and mcount on objects built for x86, ppc64le, arm64, s390, and > sparc. > > > Applies on top of: > objtool/core > > Peter Zijlstra's "x86/entry: noinstr fixes" [2] Just thought I'd note for anyone reviewing/playing with this series: Peter's patches are now in objtool/core > Sami Tolvanen's patch enabling support for more than 64k > sections in recordmcount, already going upstream. [3] Sami's patch is now in Linus' master branch Cheers, -Matt