Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp559197ybi; Fri, 26 Jul 2019 14:49:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqzEfRTMKwFp+sIM4sVmw/rsDJugVOM7HZtCBE0tUOrNCbqETEWCEoJyvfYL0EKML1jXyjUj X-Received: by 2002:a17:902:9f8e:: with SMTP id g14mr52636561plq.67.1564177756952; Fri, 26 Jul 2019 14:49:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564177756; cv=none; d=google.com; s=arc-20160816; b=U46KU5GD5ZARatB6Lx6Rky7mtRzFxHr79MnGe/nm3BaIUfKyO6hFDsDijFtDDJWEgm vToyTb4vqTGXcU9ovsZMS0xK862HbaZPd45lnjv2ao+bT7NdizV4r1UGj59TGoUlMEdc YMlC+pvmlIJ5Y8yhkrXJ6Xn4Vbr9sJyhzEuHpmfJUaBfkE74vqr7s8NzA0b2AG5hLzhG kkmjPPABeuz0jPavb9r9Ghg5hS1FrpfddG9RBMXGzbg6F1BuqqX9Mrtgyq1xFobC1wd1 osbWSa+TI8VML80lpYZavhpAhlKT1A/j4XmpBkFH2VVRFOHX2NmbZamMgJq36zyz+V3C Y7GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=+zj7XAiCZ7tQaE+QqDHDb3EqdUKAPG+Bi382rc5jvyY=; b=ZVZKbOCVFOV+SVBN0jmQ0F13QbZ/YgaRsSHXX+wwvPznBs02Y+LxB9ckmrgsoLn3Lr deZ2e4QZN9NnXgZswTRrdiOTkRRFeVfZb0B47BAC45HFgZ+Tli/RoUohtQDWLZ6w1YfC jTWi3gRecRoy2JypYjviRTnBfyl7AN4+jhsCNEbjrg61kEopoPrRjzMvPkGo8kinq72P 0ZTqc8iRq3PY61RAp7HWtfaZhZ0XqtURRkXYOyGXZ507IyXLAipmoCZWxijKKfSThQFw EiTkY7EMAWrpoj/HLEkbO96xlmdiC6k2RbEZcMHqDleYJFGp1Pk8taB4ZeyWBIc6sQZa 8seQ== 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 d25si21721753pge.301.2019.07.26.14.49.01; Fri, 26 Jul 2019 14:49:16 -0700 (PDT) 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 S2387960AbfGZRp1 (ORCPT + 99 others); Fri, 26 Jul 2019 13:45:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:42710 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387623AbfGZRp1 (ORCPT ); Fri, 26 Jul 2019 13:45:27 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BEBE421994; Fri, 26 Jul 2019 17:45:25 +0000 (UTC) Date: Fri, 26 Jul 2019 13:45:23 -0400 From: Steven Rostedt To: Matt Helsley Cc: LKML , Ingo Molnar , Josh Poimboeuf , Peter Zijlstra Subject: Re: [PATCH v3 04/13] recordmcount: Rewrite error/success handling Message-ID: <20190726134523.4e7afd55@gandalf.local.home> In-Reply-To: <316706a0e2727af0a2639b8e90366746d7a3a84a.1563992889.git.mhelsley@vmware.com> References: <316706a0e2727af0a2639b8e90366746d7a3a84a.1563992889.git.mhelsley@vmware.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Jul 2019 14:04:58 -0700 Matt Helsley wrote: Hi Matt, As I'm applying these for real, I'm taking a deeper look at the patches. This one I have some questions about. > Recordmcount uses setjmp/longjmp to manage control flow as > it reads and then writes the ELF file. This unusual control > flow is hard to follow and check in addition to being unlike > kernel coding style. > > So we rewrite these paths to use regular return values to > indicate error/success. When an error or previously-completed object > file is found we return an error code following kernel > coding conventions -- negative error values and 0 for success when > we're not returning a pointer. We return NULL for those that fail > and return non-NULL pointers otherwise. > > One oddity is already_has_rel_mcount -- there we use pointer comparison > rather than string comparison to differentiate between > previously-processed object files and returning the name of a text > section. This is fine, but it's got a strange implementation. > diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h > index c1e1b04b4871..909a3e4775c2 100644 > --- a/scripts/recordmcount.h > +++ b/scripts/recordmcount.h > @@ -24,7 +24,9 @@ > #undef mcount_adjust > #undef sift_rel_mcount > #undef nop_mcount > +#undef missing_sym > #undef find_secsym_ndx > +#undef already_has_rel_mcount Why do we need these as defines? Can't you just have a single: const char *already_has_mcount = "success"; in recordmcount.c before recordmcount.h is included? And same for missing_sym. Another, probably more robust way of doing this, is change find_secsym_ndx() to return 0 on success and -1 on missing symbol, and just pass a pointer by reference to fill the recsym (which doesn't have to be a constant). I've applied the first 3 patches of this series, but stopped here. I'll continue to take a deeper look at your other patches. Thanks! -- Steve > #undef __has_rel_mcount > #undef has_rel_mcount > #undef tot_relsize > @@ -54,7 +56,9 @@ > # define append_func append64 > # define sift_rel_mcount sift64_rel_mcount > # define nop_mcount nop_mcount_64 > +# define missing_sym missing_sym_64 > # define find_secsym_ndx find64_secsym_ndx > +# define already_has_rel_mcount already_has_rel_mcount_64 > # define __has_rel_mcount __has64_rel_mcount > # define has_rel_mcount has64_rel_mcount > # define tot_relsize tot64_relsize > @@ -87,7 +91,9 @@ > # define append_func append32 > # define sift_rel_mcount sift32_rel_mcount > # define nop_mcount nop_mcount_32 > +# define missing_sym missing_sym_32 > # define find_secsym_ndx find32_secsym_ndx > +# define already_has_rel_mcount already_has_rel_mcount_32 > # define __has_rel_mcount __has32_rel_mcount > # define has_rel_mcount has32_rel_mcount > # define tot_relsize tot32_relsize > +static const unsigned int missing_sym = (unsigned int)-1; > > /* > * Find a symbol in the given section, to be used as the base for relocating > @@ -443,9 +469,11 @@ static unsigned find_secsym_ndx(unsigned const txtndx, > } > fprintf(stderr, "Cannot find symbol for section %u: %s.\n", > txtndx, txtname); > - fail_file(); > + cleanup(); > + return missing_sym; > } > > +char const *already_has_rel_mcount = "success"; /* our work here is done! */ > > /* Evade ISO C restriction: no declaration after statement in has_rel_mcount. */ > static char const * > @@ -461,7 +489,8 @@ __has_rel_mcount(Elf_Shdr const *const relhdr, /* is SHT_REL or SHT_RELA */ > if (strcmp("__mcount_loc", txtname) == 0) { > fprintf(stderr, "warning: __mcount_loc already exists: %s\n", > fname); > - succeed_file(); > + cleanup(); > + return already_has_rel_mcount; > } > if (w(txthdr->sh_type) != SHT_PROGBITS || > !(_w(txthdr->sh_flags) & SHF_EXECINSTR))