From nobody Sun Feb 8 20:33:12 2026 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) (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 7DF6F77F1B for ; Sun, 28 Jul 2024 20:30:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722198655; cv=none; b=BQeqPaxf5iyG7Kq2u+9iXZlOPQIn6Bvdvqm5+rDeXh8878q+ms6/AKvG/oUiBzdWVI1avTytwK6iZTi/QN/zo+jFPbe93DddmvPTbdW5LmOuhtkQ3jQjAezasg3oa+PdYj/fPVC7bTiWY1txpw2swm/fu1eZXM37TYbRxrRj3lw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722198655; c=relaxed/simple; bh=FBqzozWJhNvJ4oM6y6ThYCUCO6Sc4TGcBQGQrbyCu+w=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=KNj1YhlKLTMTQSsx/zVxgEDF3c+FQXrDqKUGyXJdXbxQm2y7BqDZT4ZZrcYfqJDQDHOxKtO1OY9lAqooUJx1ogZB5qHl2XPdcWMVMHO3WWEPqkAv6CpYj9s9khqltSiYnV2VJZ2rmGpr2WT05SzzWh4NJXvS2p5Y3Ei+pdC1vV0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--xur.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=HAVlKJ+S; arc=none smtp.client-ip=209.85.219.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--xur.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HAVlKJ+S" Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-e035949cc4eso2702649276.1 for ; Sun, 28 Jul 2024 13:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722198653; x=1722803453; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=dHGeCL3vH0qLBFDWm8avFROR6jr66E4NssJlgZilgo4=; b=HAVlKJ+SJ0zr2QU0Hj8jIIqFPWrKyHppDOHwHx0bYw71kSbxvOi3wzNGlfIldXotVY XJn4QUqdeqqVQZ7aV8FWy1AvyABNTrsSIon8fGaLifNKG3jpdFsqbicdAOgbEQRbftfn 5UhiLxdmlMs5fBykUeB80RsiSKur/ydE6sFCwaDE7vuAjlFw/2fKwcAg8Vp//FZ9Cpuv n+dylMmRXCxKHoyVV3HstJvQXrE5x17xbL9C52iQu8ER9uTENgITIch54+NqnTng4GcX dD2gl07jrln7rJVH/QFxi5qAxXCsAkEAjUlNTffGJd4gyMepzFg68ddzIl6NeZDJB1WC KUeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722198653; x=1722803453; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dHGeCL3vH0qLBFDWm8avFROR6jr66E4NssJlgZilgo4=; b=LghHGIW6tY4hf/SuoAvuhKGzAQJrJ306wL4fiqsmWV2rQ/ghqGvQIW2P6ikXKWkFJd SpvMQINx7GcQ8xXYLeu7ngtKRrFKA9lbusTRfjNftw4X0Ofi1VFanpZqoqrJiMeNVZ4w uhGXIUsmP5vYLFMSaBmGGweom0aBr4ZcCzYccIe5dJfvEfPAxMRyl2BQ6MQ2Pl0EbJ5g AgQvfdevEAzfjqNBiKr1tEH7Heb5AH+29E8TMuhi3yCg2di0NnpfmflJME1283M2p61V 9/tn2oT2R1tw8E5v2L3uKaubvQkLNo13nHnWCm3Kz7XlJW3UYUbvWK7ay/3fcki00HcI fM2g== X-Forwarded-Encrypted: i=1; AJvYcCUqdAV00ibtcg7TU2PX6zWInpCuUv8VX/xO5aP7YonHlUdtiI+7DJPSpaJR11H6i63whEmmvB/fCssll6ZlItJz7e3ML3RQcOtsAkk9 X-Gm-Message-State: AOJu0Yzj+UgpmmJ2KFOiHRskFfsmOMG1YCtWf29M1WmLHdk3yMfZKPQY 1zWiZkmh41Np1SEb4h4lu5oXG7FvuI4YnWVvrv9D2vdMPD5AxPMkCyif7jySbX7K0A== X-Google-Smtp-Source: AGHT+IFbB1GtuSWiJ25Z5CJHBsZeUzd/7OcS+ZwDnzKKXYJCUjO8F45P4dz+nwWaMnszX5UCfblv1II= X-Received: from xur.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:2330]) (user=xur job=sendgmr) by 2002:a05:6902:1248:b0:e0b:10e9:88f8 with SMTP id 3f1490d57ef6-e0b545590famr362781276.8.1722198652426; Sun, 28 Jul 2024 13:30:52 -0700 (PDT) Date: Sun, 28 Jul 2024 13:29:55 -0700 In-Reply-To: <20240728203001.2551083-1-xur@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240728203001.2551083-1-xur@google.com> X-Mailer: git-send-email 2.46.0.rc1.232.g9752f9e123-goog Message-ID: <20240728203001.2551083-3-xur@google.com> Subject: [PATCH 2/6] objtool: Fix unreachable instruction warnings for weak funcitons From: Rong Xu To: Rong Xu , Han Shen , Sriraman Tallam , David Li , Jonathan Corbet , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , Ard Biesheuvel , Arnd Bergmann , Josh Poimboeuf , Peter Zijlstra , Nick Desaulniers , Bill Wendling , Justin Stitt , Vegard Nossum , John Moon , Andrew Morton , Heiko Carstens , Luis Chamberlain , Samuel Holland , Mike Rapoport , "Paul E . McKenney" , Rafael Aquini , Petr Pavlu , Eric DeVolder , Bjorn Helgaas , Randy Dunlap , Benjamin Segall , Breno Leitao , Wei Yang , Brian Gerst , Juergen Gross , Palmer Dabbelt , Alexandre Ghiti , Kees Cook , Sami Tolvanen , Xiao Wang , Jan Kiszka Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-efi@vger.kernel.org, linux-arch@vger.kernel.org, llvm@lists.linux.dev, Krzysztof Pszeniczny Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In the presence of both weak and strong function definitions, the linker drops the weak symbol in favor of a strong symbol, but leaves the code in place. Code in ignore_unreachable_insn() has some heuristics to suppress the warning, but it does not work when -ffunction-sections is enabled. Suppose function foo has both strong and weak definitions. Case 1: The strong definition has an annotated section name, like .init.text. Only the weak definition will be placed into .text.foo. But since the section has no symbols, there will be no "hole" in the section. Case 2: Both sections are without an annotated section name. Both will be placed into .text.foo section, but there will be only one symbol (the strong one). If the weak code is before the strong code, there is no "hole" as it fails to find the right-most symbol before the offset. The fix is to use the first node to compute the hole if hole.sym is empty. If there is no symbol in the section, the first node will be NULL, in which case, -1 is returned to skip the whole section. Co-developed-by: Han Shen Signed-off-by: Han Shen Signed-off-by: Rong Xu Suggested-by: Sriraman Tallam Suggested-by: Krzysztof Pszeniczny --- tools/objtool/elf.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 3d27983dc908..fa88bb254ccc 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -224,12 +224,15 @@ int find_symbol_hole_containing(const struct section = *sec, unsigned long offset) if (n) return 0; /* not a hole */ =20 - /* didn't find a symbol for which @offset is after it */ - if (!hole.sym) - return 0; /* not a hole */ + /* + * @offset >=3D sym->offset + sym->len, find symbol after it. + * Use the first node in rb_tree when hole.sym is NULL. + */ + if (hole.sym) + n =3D rb_next(&hole.sym->node); + else + n =3D rb_first_cached(&sec->symbol_tree); =20 - /* @offset >=3D sym->offset + sym->len, find symbol after it */ - n =3D rb_next(&hole.sym->node); if (!n) return -1; /* until end of address space */ =20 --=20 2.46.0.rc1.232.g9752f9e123-goog