From nobody Mon Nov 25 17:53:28 2024 Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) (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 04857178CE4 for ; Sat, 26 Oct 2024 05:14:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729919664; cv=none; b=EYfGRj48mDbab5YceoPfKPj1Hmnr00UGyEJPeE78Robtd6fl1xVIWCq5CvNhwANuMhwD2Z55XRZeLBPOduipg51eq2lsnALTzHhrYcoZXkoe+0aRj+OxvGWfcKyUZcqUY4F4miCXr6sqtWk2XG8aOphXTuCwRjw9kd1qeUyjfL0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729919664; c=relaxed/simple; bh=Q9RzV1qCGVrMb6LAeR7cFFh2RG554NMIU/BK470X3jM=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=Jiz5GCMnyKia3JULLysZl9QfwTNo7R8gZ/w7u7qPjnRbAWVePtolCucvuI3qOaXXsytpxf1PqjtiSMyE06W7A+yUTMxIvrBkKWyHwzOm8UFjVJgvwmPWrInD419h0VCr2Q2ulZWR+gey17Zy670oV0XUZ/+b7D9ScshvXK0O0sQ= 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=qKwCPbm0; arc=none smtp.client-ip=209.85.128.202 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="qKwCPbm0" Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-6e3d6713619so40413127b3.2 for ; Fri, 25 Oct 2024 22:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729919658; x=1730524458; 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=7kYFsOVpPnUjYIKUaua2wnEWHay18U0XiUGnm1LQcBI=; b=qKwCPbm0s/Ct5/MdoczSOVykrZJzITFJJDGt24nq6ymRSTWwq3AYm6eOODy/XNux9/ UHYVt2khUt5qu2COpnbfo+D0JFmcE/6bEdJdaMyN6cymDkbujmyQLo98QuzhQpXMvbkd xX/uhVYirwLEIIRHG4HSXeXPnwWjfmM90PzsOwNo/HP75FSmWQCP4ewmx1Ho1deB+plu 4kYTmvUNUwMtECD/+MRsqzGLDL3XgABNNkyXtRfU5R51C1k4bBhDk2u/ctzJhwS8feCK 7XkUqICNxaCWocyhrhqpHLiHn/vz3Mo5BuAdzuRzUNUwrUHNQR7pQyH7Kpl8yiQbDHEU ii8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729919658; x=1730524458; 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=7kYFsOVpPnUjYIKUaua2wnEWHay18U0XiUGnm1LQcBI=; b=bnkN4JduBHMJYOfqzIwm15LiABSJRjd8SJMUVsmo8PiRGrXma3mge9Xc9GGWuDa6vL j5ueeUfMgPA0Un8UjMqwcmwOZKxPfwSFEYSAMFyrtpWzCbUPv6fAf0IfwToaEHbh3Ew/ DIzypL5eXqrz0EZA9LXOkU2tIJ8Gr1JhsxS/W7NDY49SmFaedjvQxbeh3qfpxC/wlwr7 oC6VDYyG5wbruQkG5IPhwJjHe45nSdCOPEGWEf9jRndg1w7AX8lv9C6Z8qw63L3J9C/W ETTbe7M/S5nRxIcqjdmhh4rOLoTc67h1bCauM0JPAnegYc7LCHT6bwwQe12Eqd8474dU sXgg== X-Forwarded-Encrypted: i=1; AJvYcCV7xeHpjQvl4SJ2VMrjdTFPJ+zfQrr9Wml1SWlvdmaJgu6SgI7UeuZr0ReQO4Qu1God9vjcI+PtUI9pP4Y=@vger.kernel.org X-Gm-Message-State: AOJu0YyF5UB8nG3SUpUAKjqkJNimQSqZaUzkYx52uwMrE19EeTSbMKu6 aGWGQyM6iKZOdjgx2LW1HrgDasyb86Fj2DoDZh1ntQZ+r1r/S/ODbe135QY0U3yfTQ== X-Google-Smtp-Source: AGHT+IEk8vUuSuqRki7LGdU/vmd4z0u2mMux+ctpByzh8QxC1iVodNKbzUGif3YLI3VZDHQrTILJeT8= X-Received: from xur.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:2330]) (user=xur job=sendgmr) by 2002:a05:690c:6f89:b0:6e7:e3e4:9d83 with SMTP id 00721157ae682-6e9d8b5d877mr449357b3.8.1729919657990; Fri, 25 Oct 2024 22:14:17 -0700 (PDT) Date: Fri, 25 Oct 2024 22:14:04 -0700 In-Reply-To: <20241026051410.2819338-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: <20241026051410.2819338-1-xur@google.com> X-Mailer: git-send-email 2.47.0.163.g1226f6d8fa-goog Message-ID: <20241026051410.2819338-3-xur@google.com> Subject: [PATCH v6 2/7] objtool: Fix unreachable instruction warnings for weak functions From: Rong Xu To: Alice Ryhl , Andrew Morton , Arnd Bergmann , Bill Wendling , Borislav Petkov , Breno Leitao , Brian Gerst , Dave Hansen , David Li , Han Shen , Heiko Carstens , "H. Peter Anvin" , Ingo Molnar , Jann Horn , Jonathan Corbet , Josh Poimboeuf , Juergen Gross , Justin Stitt , Kees Cook , Masahiro Yamada , "Mike Rapoport (IBM)" , Nathan Chancellor , Nick Desaulniers , Nicolas Schier , "Paul E. McKenney" , Peter Zijlstra , Rong Xu , Sami Tolvanen , Thomas Gleixner , Wei Yang , workflows@vger.kernel.org, Miguel Ojeda , Maksim Panchenko , "David S. Miller" , Andreas Larsson , Yonghong Song , Yabin Cui , Krzysztof Pszeniczny , Sriraman Tallam , Stephane Eranian Cc: x86@kernel.org, linux-arch@vger.kernel.org, sparclinux@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev 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 Tested-by: Yonghong Song Tested-by: Yabin Cui Change-Id: Ib3a484b6f056db8ba4f8e91e567e3165bbeb51ea Acked-by: Josh Poimboeuf Reviewed-by: Kees Cook --- tools/objtool/elf.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 3d27983dc908d..6f64d611faea9 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -224,12 +224,17 @@ 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. + * When hole.sym is empty, use the first node to compute the hole. + * 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. + */ + 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.47.0.163.g1226f6d8fa-goog