Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp5254016pxb; Mon, 15 Feb 2021 14:11:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJz5vQapFoJ+IYBA3QoPGVY4tjKZLXg96QQfTwYQ7pXQaF46nqsVWDukHdHVP1USlbHH2Dx4 X-Received: by 2002:a17:906:8287:: with SMTP id h7mr10020193ejx.222.1613427090079; Mon, 15 Feb 2021 14:11:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613427090; cv=none; d=google.com; s=arc-20160816; b=i8Kb/G/LCkyevKOusIh2kK89p8BAI5MtKiP78jg9RcHsLk6uGB0gPcQWldo5oaCuCJ qu3GMEBf1sZyeU8eDFppZ3JnGGQqOw0VwoIszMYivdqPeVtgOJjflLIeBZp+wkMiStqR peNTZwLuDd+TEiXYIPzwHqWELV4MTpSdvZ+zOFkTtya8xTOx89IBjmzg971ydd4GK9XO K8Wyfl6HlWjXr4YNKIaSX0RD7Ira6FjI9AimEMbOItrw5+vRoCpO3Fl+Jq6oywzv0pHr gJ7HCiWXyuPdLIMw/iRGyU/01fBQqaU1LhKC9TR9GdjYwR98TsDP8Q3iJmbDjEHZefmc ePYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=8sRsKy4isMGY7sAtQBJA5SejF9rBRfd+Ntb2s6JTMwU=; b=qrWMjO8wC6hEm2wh0p7Bn7w+XZMS/EowlZP9fGgd1PseMUt/aH6nSnBw5teS9qth78 kwQqSjh+k/c9BgnCVN9T3YefCKDQA6STiKi1N/XT1q0CZh6Teh8MkhCVFPW9RPtdJLDt rZD+cFP0v+vFo+8i8DlKIaGmwg7RebXn2Sc0DgC5wYfV2VFB3pUrwxWJtp2bGbB6Mona kdKBJKMlkxEynoP75y/RLhtctu0P2Q204pUdMWf+tLOyUQYDlZ+lupUf7JWLjKN1Wzgq nHB4b5zQmg35Yx2iCUB6lHn2g0UjI9/wXD53kv0kiisvyYJqI48S9WoTc+Bncj5t4Aoi +iIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v5si12351361eji.385.2021.02.15.14.11.06; Mon, 15 Feb 2021 14:11:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229720AbhBOVWy (ORCPT + 99 others); Mon, 15 Feb 2021 16:22:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:58456 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229662AbhBOVWx (ORCPT ); Mon, 15 Feb 2021 16:22:53 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3449364DE0; Mon, 15 Feb 2021 21:22:11 +0000 (UTC) Date: Mon, 15 Feb 2021 16:22:09 -0500 From: Steven Rostedt To: Josh Poimboeuf Cc: Greg Kroah-Hartman , 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: <20210215162209.5e2a475b@gandalf.local.home> In-Reply-To: <20210215155806.bjcouvmkapj4pa4y@treble> References: <20210212170750.y7xtitigfqzpchqd@treble> <20210212124547.1dcf067e@gandalf.local.home> <20210213091304.2dd51e5f@oasis.local.home> <20210213155203.lehuegwc3h42nebs@treble> <20210214155147.3owdimqv2lyhu6by@treble> <20210215095307.6f5fb12f@gandalf.local.home> <20210215155806.bjcouvmkapj4pa4y@treble> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 15 Feb 2021 09:58:06 -0600 Josh Poimboeuf wrote: > On Mon, Feb 15, 2021 at 09:53:07AM -0500, Steven Rostedt wrote: > > On Sun, 14 Feb 2021 09:51:47 -0600 > > Josh Poimboeuf wrote: > > > > > 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. > > > > When does the .text.unlikely section disappear? During the creation of the > > object, or later in the linker stage? > > The section is there, but the symbol associated with the section > (".text.unlikely" symbol) isn't generated by the assembler. > Greg, Does this fix the issue with you? It appears to fix it for my arch linux VM that I created that uses binutils 2.36-3. -- Steve diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h index f9b19524da11..558b67f8364e 100644 --- a/scripts/recordmcount.h +++ b/scripts/recordmcount.h @@ -562,7 +562,7 @@ static char const * __has_rel_mcount(Elf_Shdr const *const relhdr, /* reltype */ if (w(txthdr->sh_type) != SHT_PROGBITS || !(_w(txthdr->sh_flags) & SHF_EXECINSTR)) return NULL; - return txtname; + return shdr0->sh_size ? txtname : NULL; } static char const *has_rel_mcount(Elf_Shdr const *const relhdr,