Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp665220ybt; Wed, 17 Jun 2020 10:40:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzRpl9HTXzwCAPxeD/f2SB86yCaSRdHA7HD3UGaiHuJkMlrNY6l8nbWJJf4f+24rUjPVHsT X-Received: by 2002:a17:906:f74a:: with SMTP id jp10mr262916ejb.43.1592415633470; Wed, 17 Jun 2020 10:40:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592415633; cv=none; d=google.com; s=arc-20160816; b=DGV5qOt46J57MwzgJTo90RAj2vgvsWL1xjlN9jsZFH/x4qSS3iwC0p25QOu83C8UY3 1+ARVYH7C2IwLjn7Xw6IdSr8tTeH/g8DSLVdgaNY5SNYL5t7My4O5YspQJXY2BENeico Ud96ZbbrMoCUIfQ1ueBcIrksUt4nRBx5WeaPc5SKV17yGARAYfCNUYQ3r2S0ScLL3jED 6lIg3XKNzVl+jvkoqh2DRNooPzlgiBXqbF0gXwGdsl9lSIG22NZoSVMi+6N9SSMPlaFL 48jDISmfz6TH4lk25Ssapw84/HUyUL92Jw99LQ07KFxG0KNQDxu9rT5yo70TIR5WMFTw uCwQ== 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=6IXOh00O4p5wPu5Cir/w5gl3JqOdPdeomJuRRdk/3cc=; b=cw7BIwI1D9Z33vzEq0YSDe9tRvxmZQ5zug3rVe+Gzvqf3bfP0bECj2jQwkLivvr8pg 7rAjFALgkkwV3PMLVYpW3gf/h01XSC07mcb5+JpfWVgIVT8esZo8xK2IfXCbP+6sEtQ1 G1TyHj9hmT74ECKqsd/4jSz/W7Sq5tjXHaYZTFniu/QbHHrwpRubRB+25NpDwrVYjPH1 AAidgUSslEmyq8HPs1abkRUN6FzuFiMXIFvPGY15SG3Oth7Qw91m4Qlj8vfNh0FFYbuR yYr4zUcm/IrIVKb8rjXoxtEWLdN2lHubm5WMAYPmp2I9JE/8nefgIN4ES2LCjNPggehX Ewqg== 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 v22si396302edy.558.2020.06.17.10.40.10; Wed, 17 Jun 2020 10:40:33 -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 S1726845AbgFQRgX (ORCPT + 99 others); Wed, 17 Jun 2020 13:36:23 -0400 Received: from ex13-edg-ou-001.vmware.com ([208.91.0.189]:30648 "EHLO EX13-EDG-OU-001.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726511AbgFQRgX (ORCPT ); Wed, 17 Jun 2020 13:36:23 -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; Wed, 17 Jun 2020 10:36:18 -0700 Received: from localhost (unknown [10.200.193.92]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id A5EDE4006D; Wed, 17 Jun 2020 10:36:20 -0700 (PDT) Date: Wed, 17 Jun 2020 10:36:20 -0700 From: Matt Helsley To: Peter Zijlstra CC: , Josh Poimboeuf , Steven Rostedt , Sami Tolvanen , Julien Thierry , Kamalesh Babulal Subject: Re: [RFC][PATCH v4 18/32] objtool: mcount: Move nop_mcount() Message-ID: <20200617173620.GA89648@rlwimi.vmware.com> Mail-Followup-To: Matt Helsley , Peter Zijlstra , linux-kernel@vger.kernel.org, Josh Poimboeuf , Steven Rostedt , Sami Tolvanen , Julien Thierry , Kamalesh Babulal References: <7109ceb239a88c2901eeb7f52c29f69cdb413cd3.1591125127.git.mhelsley@vmware.com> <20200612132656.GQ2531@hirez.programming.kicks-ass.net> <20200612160534.GD2554@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200612160534.GD2554@hirez.programming.kicks-ass.net> 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 Fri, Jun 12, 2020 at 06:05:34PM +0200, Peter Zijlstra wrote: > On Fri, Jun 12, 2020 at 03:26:57PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 02, 2020 at 12:50:11PM -0700, Matt Helsley wrote: > > > +static int nop_mcount(struct section * const rels, > > > + const char *const txtname) > > > +{ > > > + struct reloc *reloc; > > > + struct section *txts = find_section_by_index(lf, rels->sh.sh_info); > > > + unsigned mcountsym = 0; > > > + int once = 0; > > > + > > > + list_for_each_entry(reloc, &rels->reloc_list, list) { > > > + int ret = -1; > > > + > > > + if (!mcountsym) > > > + mcountsym = get_mcountsym(reloc); > > > + > > > + if (mcountsym == GELF_R_INFO(reloc->sym->idx, reloc->type) && !is_fake_mcount(reloc)) { > > > > This makes no sense to me; why not have mcountsym be a 'struct symbol > > *' and have get_mcountsym() return one of those. > > > > if (reloc->sym == mcountsym && ... ) > > > > is much nicer, no? (this is already incorporated in my unposted revisions but...) > > On top of that, I suppose we can do something like the below. > > Then you can simply write: > > if (reloc->sym->class == SYM_MCOUNT && ..) This looks like a good way to move towards a "single pass" through the ELF data for mcount. What order do you want to see this patch go in? Before this series (i.e. perhaps just a kcov SYM_ class to start)? Early or late in this series? After? Right now I'm thinking of putting this on the end of my series because I'm focusing on converting recordmcount in the series and this isn't strictly necessary but is definitely nicer. > > --- > > diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile > index 45452facff3b..94e4b8fcf9c1 100644 > --- a/kernel/locking/Makefile > +++ b/kernel/locking/Makefile > @@ -1,7 +1,7 @@ > # SPDX-License-Identifier: GPL-2.0 > # Any varying coverage in these files is non-deterministic > # and is generally not a function of system call inputs. > -KCOV_INSTRUMENT := n > +# KCOV_INSTRUMENT := n > > obj-y += mutex.o semaphore.o rwsem.o percpu-rwsem.o > > diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c > index 432417a83902..133c0c285be6 100644 > --- a/tools/objtool/elf.c > +++ b/tools/objtool/elf.c > @@ -341,6 +341,24 @@ static int read_sections(struct elf *elf) > return 0; > } > > +static bool is_mcount_symbol(const char *name) > +{ > + if (name[0] == '.') > + name++; > + > + if (name[0] == '_') > + name++; > + > + return !strcmp(name, "mcount", 6) || Looks like you intended this to be a strncmp() but I don't see a reason to use strncmp(). Am I missing something? > + !strcmp(name, "_fentry__") || > + !strcmp(name, "_gnu_mcount_nc"); > +} This mashes all of the arch-specific mcount name checks together. I don't see a problem with that because I doubt there will be a collision with other functions. Just to be careful I looked through the Clang and GCC sources, though I only dug through the history of Clang's output -- GCC's history with respect to mcount symbol names across architectures is much harder to trace so I only looked at the current sources. (the rest looks good) Cheers, -Matt Helsley