From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FFFCC433E0 for ; Sun, 14 Feb 2021 15:53:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F18F164DDD for ; Sun, 14 Feb 2021 15:53:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229836AbhBNPxa (ORCPT ); Sun, 14 Feb 2021 10:53:30 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:27306 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229730AbhBNPx0 (ORCPT ); Sun, 14 Feb 2021 10:53:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613317918; 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=b0So7W4a4U2tcf26Y/zPdxj6J7yWSOARMMAY/QxHwq8=; b=OB44cxlpxPgOAoKgJhgBG7IEzuJb4g92Y41ieE9YUN/ZKqjfN+B7IbmiXNoIgTYYi7JXiL 6sYguT83JRAzQh6z0oBdlKh9zRvxdxx7ue0W2sTC32VVj7xzMe+MK9PivP9v+ih9+Iist0 UqWFGGFaH+gmNZu5HqezpCkBbbDgmUo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-243-svSsil19MpCJuxoQ9NQ19Q-1; Sun, 14 Feb 2021 10:51:53 -0500 X-MC-Unique: svSsil19MpCJuxoQ9NQ19Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ECA46192AB79; Sun, 14 Feb 2021 15:51:51 +0000 (UTC) Received: from treble (ovpn-120-169.rdu2.redhat.com [10.10.120.169]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2BA9B10021AA; Sun, 14 Feb 2021 15:51:49 +0000 (UTC) Date: Sun, 14 Feb 2021 09:51:47 -0600 From: Josh Poimboeuf To: Greg Kroah-Hartman Cc: Steven Rostedt , Nick Desaulniers , Xi Ruoyao , "# 3.4.x" , Arnd Bergmann , "Peter Zijlstra (Intel)" , Miroslav Benes , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , LKML , linux-tip-commits@vger.kernel.org Subject: Re: [tip: objtool/urgent] objtool: Fix seg fault with Clang non-section symbols Message-ID: <20210214155147.3owdimqv2lyhu6by@treble> References: <20210212170750.y7xtitigfqzpchqd@treble> <20210212124547.1dcf067e@gandalf.local.home> <20210213091304.2dd51e5f@oasis.local.home> <20210213155203.lehuegwc3h42nebs@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 13, 2021 at 05:25:18PM +0100, Greg Kroah-Hartman wrote: > On Sat, Feb 13, 2021 at 09:52:03AM -0600, Josh Poimboeuf wrote: > > On Sat, Feb 13, 2021 at 09:13:04AM -0500, Steven Rostedt wrote: > > > On Sat, 13 Feb 2021 15:09:02 +0100 > > > Greg Kroah-Hartman wrote: > > > > > > > Thanks for the patch, but no, still fails with: > > > > > > > > Cannot find symbol for section 8: .text.unlikely. > > > > kernel/kexec_file.o: failed > > > > make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1 > > > > make[1]: *** Deleting file 'kernel/kexec_file.o' > > > > > > It was just a guess. > > > > > > I guess I'll need to find some time next week to set up a VM with > > > binutils 2.36 (I just checked, and all my development machines have > > > 2.35). Then I'll be able to try and debug it. > > > > FWIW, I wasn't able to recreate. I tried both binutils 2.36 and > > 2.36.1, with gcc 11 and a 'make allmodconfig' kernel. > > I'm using whatever the latest is in Arch, which is gcc 10.2 and binutils > 2.36. My config is here: > https://github.com/gregkh/gregkh-linux/blob/master/stable/configs/4.4.y Ok, I was able to recreate with that config. GCC places two weak functions (arch_kexec_apply_relocations_add() and arch_kexec_apply_relocations()) in .text.unlikely (probably because printk() is __cold), and then the assembler doesn't generate the '.text.unlikely' symbol because no other code references it. Steve, looks like recordmcount avoids referencing weak symbols directly by their function symbol. Maybe it can just skip weak symbols which don't have a section symbol, since this seems like a rare scenario. Here's a total hack fix. Just remove the functions, awkwardly avoiding the problem. diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 6030efd4a188..456e3427c5e5 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -115,24 +115,6 @@ int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, return -EKEYREJECTED; } -/* Apply relocations of type RELA */ -int __weak -arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, - unsigned int relsec) -{ - pr_err("RELA relocation unsupported.\n"); - return -ENOEXEC; -} - -/* Apply relocations of type REL */ -int __weak -arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, - unsigned int relsec) -{ - pr_err("REL relocation unsupported.\n"); - return -ENOEXEC; -} - /* * Free up memory used by kernel, initrd, and command line. This is temporary * memory allocation which is not needed any more after these buffers have