Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3108227pxm; Mon, 28 Feb 2022 12:10:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJyThQGo0HDQUSudJ0HojzGuhg5dCPoSpZmCGF199pRNmKmdQm+pov+hVTwkevzFWs+L+g0e X-Received: by 2002:a63:1c21:0:b0:374:104c:e4eb with SMTP id c33-20020a631c21000000b00374104ce4ebmr18625502pgc.556.1646079036937; Mon, 28 Feb 2022 12:10:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646079036; cv=none; d=google.com; s=arc-20160816; b=QUJZiK/M97kQhkAiP0UWacbJ/wSuxUsGtcpaVlXFuOXVBqp9QmPY7euMJJd1EQZZmZ ADJro6BUZnx6TrQTSyytZMaG5xVaBLd8asn8T3AGfHiB01k2/W8igAfXGDimZfVbDAO9 D5IzzQuOy8+h07vdhGohjZAlQaOoinpvy9QFxbNDkIB4yKahvIdiOKsGLbKnKa6SSixG I7qD5Mz3SPOeLZ0BXqFDNlGL/Y/531hImLNLehKv/wxXLG2NomnUbHkYQONTlLpuvT1+ qlwN+WRzKIDmQtuM/cFEtjEMJn3ouehD3dCH7Yfuyray1Q57yxkcgbeNzCYymlLEblpo Xbqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=1t6rYRbTMQR99dgTTwzmR0JbGj6Nz3pGfTv0NpS6LGk=; b=zOdAKia2JbQevE/my4TIcxgv+NXY8CesOMvpwNMaQVSzn5C5215Thr4O7qrXZecQAO hbT+ZuAYuzB+Km3Maw7k8z5GXDW27S8w6GJ71BjNoqT6jpg8JCgTmYEJdLxIHuhKf3jF P4dPLi31DrYXxnqimUBYwvWAnzl4nLaWj2qleiN2Yzqi48N48JG3kAtOWbqoHiSpCXnl T0MVnyvLrBHPYPzOxDjKwCSjFEsc/+Kfv1/1oE85ADf+Po0WbjKLDSbO5vtVgjWlYH5M kv2Do9MdjQ9xncOGuvbUh7PczSNFsKz8c3wA5XQn5gRHHiFMj7TOHYj6Oqkhy1C/7Tz+ vudQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CEDg+T4L; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id c9-20020a634e09000000b0037835828227si9090869pgb.398.2022.02.28.12.10.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 12:10:36 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CEDg+T4L; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BCA2D14CC80; Mon, 28 Feb 2022 11:34:32 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240635AbiB1Sl2 (ORCPT + 99 others); Mon, 28 Feb 2022 13:41:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240697AbiB1SkV (ORCPT ); Mon, 28 Feb 2022 13:40:21 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 94C2424596 for ; Mon, 28 Feb 2022 10:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646073155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1t6rYRbTMQR99dgTTwzmR0JbGj6Nz3pGfTv0NpS6LGk=; b=CEDg+T4L1Me93wwUV5hyx74ud/Wtv08W9uUudIt69IBCyeLwy9w+V1+ZdYts+ymWN/N4N5 4+XW74MNufYIU4ZKS1W2TbZZxJp8U/43g9I9RrzqVogMB10XmdXTygN/8uadIExuqGQegj cDWTpDGkBpiAuf3Oe+jdsPPUMVJKcLM= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-176-GiTrhr1UNDGgPCkH4G3DCw-1; Mon, 28 Feb 2022 13:32:33 -0500 X-MC-Unique: GiTrhr1UNDGgPCkH4G3DCw-1 Received: by mail-qv1-f69.google.com with SMTP id z3-20020a0cf003000000b004328f6a7131so12538127qvk.19 for ; Mon, 28 Feb 2022 10:32:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=1t6rYRbTMQR99dgTTwzmR0JbGj6Nz3pGfTv0NpS6LGk=; b=yqmAlOOrb5qndGdmC8F7h915UYADMlx8549/0eHf/DNPlGWXGaXj2DFK3zcYShorVP 0Kh8EYSj/WD0Vdg/5qs6v8oqi9LKINs2lnHvJj2UeL0i4xaEC7YZVYQxvFBQ9Bj6MOIg GXemjeOsnT/r7ZNWrLRdOBxLc7WsSNiPpnG5tBZGp9RoftXkxoG9WuCCQN/DxDoLXuN8 v1A9Yv2uvhlMUkalQa6j/IGU5E+TqZ8mYVJ9QcQD45yg1XFBxzZ76yeS0XGDylu1bhKR KIXngILUoZ8aiqm+7YYg9fiX1lXmxzIUorShfT71D6LE14rstP63CXT+sMzCvfZ8sYCt sSzA== X-Gm-Message-State: AOAM530LWlvXthQ9Z/pSEBV2UVF9WJzcu8uwDx2Axz6tPKiU5LQBYXoy G1zhcd11aXvkZDvhlEDqdXNFP72GUC44ZplkO/gKlN3WmgHgpSXxfJC/skmHUvqS8MY0racVqRZ SA/OvADDHZj8ldXcmuDpiwu32 X-Received: by 2002:a05:622a:40e:b0:2df:f698:f1ef with SMTP id n14-20020a05622a040e00b002dff698f1efmr8420578qtx.595.1646073153379; Mon, 28 Feb 2022 10:32:33 -0800 (PST) X-Received: by 2002:a05:622a:40e:b0:2df:f698:f1ef with SMTP id n14-20020a05622a040e00b002dff698f1efmr8420541qtx.595.1646073153037; Mon, 28 Feb 2022 10:32:33 -0800 (PST) Received: from treble ([2600:1700:6e32:6c00::45]) by smtp.gmail.com with ESMTPSA id e9-20020a05620a014900b005084ce66b44sm5347108qkn.88.2022.02.28.10.32.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 10:32:31 -0800 (PST) Date: Mon, 28 Feb 2022 10:32:28 -0800 From: Josh Poimboeuf To: Peter Zijlstra Cc: x86@kernel.org, joao@overdrivepizza.com, hjl.tools@gmail.com, andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org, ndesaulniers@google.com, keescook@chromium.org, samitolvanen@google.com, mark.rutland@arm.com, alyssa.milburn@intel.com Subject: Re: [PATCH 21/29] objtool: Rename --duplicate to --lto Message-ID: <20220228183228.splleoatuxxjr5kq@treble> References: <20220218164902.008644515@infradead.org> <20220218171409.814392411@infradead.org> <20220226194209.bvv3t65hhtnwltmk@treble> <20220226214802.4chmsrtstlerefmu@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 28, 2022 at 12:05:06PM +0100, Peter Zijlstra wrote: > > It just dawned on me that "--noinstr" already exists. But I'm > > scratching my head trying to figure out the difference between > > "--noinstr" and omitting "--lto". > > If you run: "objtool check --vmlinux --noinstr vmlinux.o", it'll only do > the shallow .noinstr.text/.entry.text checks. If OTOH you do: "objtool > check --vmlinux --noinstr --lto vmlinux.o" it'll do everything > (including noinstr). I think I got all that. But what does "--vmlinux" do by itself? > Similarlt, "--module --lto" will come to mean whole module (which is > currently not distinguishable from a regular module part run). > > (barring the possible 's/--lto/--whole-archive/' rename proposed up top) Thanks for the explanations. To summarize, we have: A) legacy mode: translation unit: objtool check [--module] vmlinux.o: N/A module: N/A B) CONFIG_VMLINUX_VALIDATION=y && !(CONFIG_X86_KERNEL_IBT=y || CONFIG_LTO=y) translation unit: objtool check [--module] vmlinux: objtool check --vmlinux --noinstr module: objtool check --module --noinstr C) CONFIG_X86_KERNEL_IBT=y || CONFIG_LTO=y: translation unit: N/A vmlinux: objtool check --vmlinux --noinstr --lto module: objtool check --module --noinstr --lto Right? I think I get it, but it's mental gymnastics for me to remember how the options interact. It still seems counterintuitive, because whatever "objtool check" does to a translation unit, I'd expect "objtool check --vmlinux" to do the same things. I suppose it makes sense if I can remember that --vmlinux is a magical option which disables all that other stuff. And it's counteracted by --lto, which removes the magic. But that's all hard to remember and just seems weird. There are a variety of ways to run objtool against vmlinux. The "lto" approach is going to be less of an exception and may end up being the default someday. So making --vmlinux do weird stuff is going to be even less intuitive as we go forward. Let's make the default sane and consistent with other file types. So how about we just get rid of the magical --vmlinux and --lto options altogether, and make --noinstr additive, like all the other options? A) legacy mode: .o files: objtool check [--module] vmlinux: N/A module: N/A B) CONFIG_NOINSTR_VALIDATION=y && !(CONFIG_X86_KERNEL_IBT=y || CONFIG_LTO=y): .o files: objtool check [--module] vmlinux: objtool check --noinstr-only module: objtool check --module --noinstr-only C) CONFIG_X86_KERNEL_IBT=y || CONFIG_LTO=y: .o files: N/A vmlinux: objtool check --noinstr module: objtool check --module --noinstr (notice I renamed VMLINUX_VALIDATION to NOINSTR_VALIDATION) Isn't that much more logical and intuitive? a) objtool has sane defaults, regardless of object type b) no magic options, other than --noinstr-only, but that's communicated in its name c) --vmlinux is no longer needed -- fewer options to juggle -- Josh