From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 221AC32824A for ; Mon, 17 Nov 2025 09:42:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763372538; cv=none; b=a0ZJIxsSNR7FvD5+UHPHgUaAS3OApe4NDXXh4W1V43hjmKwlHCsERFdZh9t2KGIZI+UY0rfmBYQIaoz7BjjfGMoXEzKg/lk0s+yxgj2/Lf+47YhV50cUEZ+0V2d3Lv1BUXyEtw/jQOUmh87+C/SC7qoSKF/DJwpH3h87vo7R1dY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763372538; c=relaxed/simple; bh=5W7vV61faOxGNh+kfJR/3ZOCFddYqw/2buZBdGkJ4MI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Bt3nn2un/rmdZctXSTkuNyhx47eNmCw4YCEynIf/7cCUIDyIbDhGie8Q0I0FUkAh5nZ6zyp0Rs1yEhrVN0vM4d4z/NVbk7v1sD0UBIZx4a4jBRs0KO+79PfPi1JKVYmxiUQy/aw15H4HdNpjoTqlg8beTE4O6H0+MS28YYZeN0g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=F9Kp+NL/; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F9Kp+NL/" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4779a637712so10429935e9.1 for ; Mon, 17 Nov 2025 01:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763372535; x=1763977335; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=fjoeRM0ulfkjiJoiMzsNObBjgfm/UTC6Eth1kAud0ys=; b=F9Kp+NL/rIQLcDOjMQ0Xv7/JGqOjfKJL4LwwyjteMqUtqAZUdmOhGwyF7vsfa5xJoV GUwb5GSdmmSVNiNo+lQEThuIyy+0JB9k4PZR68TZfbMS3der5FnoQFOBy6SYR1Vu2cpI F/jqlQAdUXkQ4IvyG6bHRBC1tGqMPx3tHYKEnceW3DJwjMnFJLKBB6sPUH7if+gE0LHU lasYzV+yrXzSPvQVM/BSp49cdvydFqkCT1iMt4MKw91KgT5ha/RV+UH3XSLhK3MLwBD1 8Edd10xQqCxZkRSSVzlwt7xIzCnRVJ9OiHYyA3dolEsKN08RoBRFoqaMcqqyu7pRhEct Uqeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763372535; x=1763977335; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=fjoeRM0ulfkjiJoiMzsNObBjgfm/UTC6Eth1kAud0ys=; b=P8623Vmt2IX6A8IZdziJNZkgafocqK5UjoOsl1JLP9gNZbOqiRvzIz2sTyeiRdzVfx dwobqqs6FwX61p31k9N4/GGpmjNubkwcf8E5AptXDDaGpTl5MjErq5hzoXGmcBO4WRAL vMpB51tZPTabQe3OwLbik6dydWLLcQ3wJw1VskDSzaXSRQagBz7EnGLNifd/+4Ghs+vE YxtGpiOxeButOoiZilB/idcN/hR1GjFMQPu/36QwX/YhFyTOmH4A+8+pQdLoJclLXqxS 8G7lJo1zUqRJ8pCWLktymbPSRf1kKq1Bgg0Mg0KTGMAY3LKWKvmIpDV6DAEVixXlP+kL bTIg== X-Forwarded-Encrypted: i=1; AJvYcCW5Q4CFHCJsDZZxH3emB8MmuNmOxdb7D+aWXwIkki28yXuSFO3gqBjxXLi7wWHvwGc03+UMrWEwO5Rz1vk=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5963QgJTCf/+elWyOAK6lrmktjagSHkA+MKU6IanshaZPllWd skudJVVTIyeefzu5yJ0ToY9woT78p7Kp98gm9iDxR5k8qfHjEz8ucAcE X-Gm-Gg: ASbGncsu5KspzeLqB5gU7Y8UfvrUyYOp95N52zQOq0toNak3D16OQTXeTpNwq6G/849 pKc9n3xjBc+nXRgFiTxUnBnngRck7jy69Wg7dgfZtQu8bL+qgiLAms36mXCrODgbBITUsrFsemX /ix6YQ9mE7NeyU+F5gUjjU3S8dLv1uSNyZ/etGf2SEDVV8eZobtxjDijEwNiNHQVRJfXFcox/Xt abvRNs7f2SYuSvZEX8qjMJGCEFhgvdfmLu/zNKnpW2V/waf6SGHncbth+1dHuDqF5kgCe66qfxO sf4MSjzrT9xXTcqhq/fIHTyAZUHdN2qrYhUQja+rklBQP6kp5mM4eZpeMRYFw1uCAyjqXXG0pfm dSWIH5xvt/kX0JkQrmBwUUM922JAhUjfrMFNvoZ53ZLSmm8L4rQCdt62EnQjWDGe1bTN1Exy1H6 bJ+IghuDsjonuRLBG/6lymEMXs4psLCMRCfVumMaK3UmaI34woxwtx X-Google-Smtp-Source: AGHT+IEQxDb+tgY2fLHYXOXBIyuiXN26r9Trc54rPIT3HQ7IIREqdGiCYFJr5lbdjgQp29tgDj1y9Q== X-Received: by 2002:a05:600c:1caa:b0:477:76cb:4812 with SMTP id 5b1f17b1804b1-4778fe0694amr121657585e9.0.1763372534926; Mon, 17 Nov 2025 01:42:14 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4778bb34cc1sm106447205e9.3.2025.11.17.01.42.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Nov 2025 01:42:14 -0800 (PST) Date: Mon, 17 Nov 2025 09:42:10 +0000 From: David Laight To: Alexandre Chartre Cc: Josh Poimboeuf , linux-kernel@vger.kernel.org, mingo@kernel.org, peterz@infradead.org Subject: Re: [PATCH v4 00/28] objtool: Function validation tracing Message-ID: <20251117094210.3c3e4f40@pumpkin> In-Reply-To: References: <20251113164917.2563486-1-alexandre.chartre@oracle.com> <3367da83-16b7-4c6a-bd08-d14ec4067025@oracle.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 17 Nov 2025 08:50:45 +0100 Alexandre Chartre wrote: > On 11/14/25 22:34, Josh Poimboeuf wrote: ... > David raises the issue that a side-by-side display requires a large window. > > The compact display could be like this: > > Alternative with single instruction: > > bb8: do_one_initcall+0x1a8 > = callq *0x0(%rip) # 0xbbe (if default) > = sti (if !X86_FEATURE_XENPV) > = callq BUG_func (if +X86_FEATURE_ALWAYS) > > Alternative with multiple instructions: > > 82e7: __switch_to_asm+0x27 > = DEFAULT > 82e7: __switch_to_asm+0x27 | jmp 0x8312 <__switch_to_asm+0x52> > | > = !X86_FEATURE_ALWAYS > 82e7: __switch_to_asm+0x27 | NOP1 > 82e8: __switch_to_asm+0x28 | NOP1 > 82e9: __switch_to_asm+0x29 | callq 0x82ef <__switch_to_asm+0x2f> > 82ee: __switch_to_asm+0x2e | int3 > 82ef: __switch_to_asm+0x2f | add $0x8,%rsp > 82f3: __switch_to_asm+0x33 | lfence > | > = X86_FEATURE_RSB_CTXSW > 82e7: __switch_to_asm+0x27 | mov $0x10,%r12 > 82ee: __switch_to_asm+0x2e | callq 0x82f4 <__switch_to_asm+0x34> > 82f3: __switch_to_asm+0x33 | int3 > 82f4: __switch_to_asm+0x34 | callq 0x82fa <__switch_to_asm+0x3a> > 82f9: __switch_to_asm+0x39 | int3 > 82fa: __switch_to_asm+0x3a | add $0x10,%rsp > 82fe: __switch_to_asm+0x3e | dec %r12 > 8301: __switch_to_asm+0x41 | jne 0x82ee <__switch_to_asm+0x2e> > 8303: __switch_to_asm+0x43 | lfence > 8306: __switch_to_asm+0x46 | movq $0xffffffffffffffff,%gs:0x0(%rip) # 0x20b <__x86_call_depth> That does looks better. Although I think there ought to be some indication of the 31 NOP bytes at the end of the middle alternative. I'd also decode those callq as 'callq .+6' - not sure what other people think? It is rather specific to that code. David