Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp5051003rwb; Tue, 6 Sep 2022 17:51:42 -0700 (PDT) X-Google-Smtp-Source: AA6agR4v1k1Ii3k2VqlrqIObg4MOBw5+SwSdNXmoOw6N8/OQuY1HZoDk6i3rTOWBrdiX7yl49TMu X-Received: by 2002:a17:906:cc16:b0:73d:d16c:609f with SMTP id ml22-20020a170906cc1600b0073dd16c609fmr663221ejb.691.1662511901810; Tue, 06 Sep 2022 17:51:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662511901; cv=none; d=google.com; s=arc-20160816; b=okDFv+i5IgmDqEizEXiJkuml0UWUnOcAmMdcVlNICOMck5enU1wffjy6h0s9On/C5W mSBhDEWLKx1yEgPJiT76TFqHoY6z/L82lXOb3QnJ0BGHaNu5P5xwxwuJlQo496g6Rczs ymok02tz+JHmVuMDHuiaUloI+uCYmKrYGLDZyeZapTKgIll/NUEwK8Nt+J5ZTukQE/Ic nufTY+MB54C5f95DouNw6Ej7T1RscHnRuwMLRTn7immMlxRkWbnVryT545PGlZXUTPDc HgjiHY0QzxTNQDmqPKJACkMfGK8CzFlKGlIguu2dMFQT8aYEy6twa6b1yrD0xHLt92ZD iNHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=hxTBhCI0F5j/2VZXRiH27pSDCjgcW9IAx9MdqUjicTA=; b=E/rdOUAsBSPMZR8uNkPPgEzEsxwst8fXMn845euGbb40nyjPFWuw68U2q2hHFfqita 83+KIDXg4K5w+/2qDeJ8xIL7y9VP2L549HWojGNzhsTT33s3UAfEi70gTNP1noMNkEm0 cTtmf8xLa7p9MLaaWGBwUMsESZNH027TNZKhKRUV61IEjxaYde0C7zdF7wXTwxjcCEQI 5WWQ6abXIPP1hdVLFwEVwP/U2hIYPKRm4tPzpAzsRCEnFDKzrrj2dXVzsB2+Wf2+NaDa xpHg/yvKbjq6tGigJpU1yyqiUlsClEf9aXLLxHZkP4AjxR+HULBsUMMMzXQazE+9aQMv Q4jQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pR0smMM+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x69-20020a50bacb000000b0044816827be2si9286018ede.314.2022.09.06.17.51.16; Tue, 06 Sep 2022 17:51:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=pR0smMM+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229585AbiIGAsC (ORCPT + 99 others); Tue, 6 Sep 2022 20:48:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbiIGAsB (ORCPT ); Tue, 6 Sep 2022 20:48:01 -0400 Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2ACC2915FA for ; Tue, 6 Sep 2022 17:48:00 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id i1so13363103vsc.9 for ; Tue, 06 Sep 2022 17:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=hxTBhCI0F5j/2VZXRiH27pSDCjgcW9IAx9MdqUjicTA=; b=pR0smMM+P4+BPyuL8kqpu+hfHMn3uKgzZOeKg9mikK3AiGbd0DWuHgG+Ra594j7mlA keOMF9a3Y46gU9rbxjugz3wWlG3T8QukRsf3y8Rfub8s5BCFL8nILhBJReOt4k0Ze/4f 7j6gzOn5rU/1tMtEbAZpVPzWik3n5wsuI3/2D34KI4Mk4/sv1YIekuy9NHbKrejDL4eM JG4WPD1rj8LdelhXF7X/zzPKqfX3mE25wiGo9gBB6Q4637lCO/1A/H4yz+9lIzEryDVc ptvvZh3+MYf2U3to8X3w5gliceYUgwUFd2sOTcSUCGTLsRAEH1naWSPjYzDNVXDYY4am udgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=hxTBhCI0F5j/2VZXRiH27pSDCjgcW9IAx9MdqUjicTA=; b=7SV+j8ug/DphsfnF/x+9i/7J5Os3kvMMT0lPvz+pungDL0740Z2mkXdL4cgWF95OMX 5d997L/f8Xv3QD3rAm9od3UvSWbnxNY4w7Kkab9SMmWFURJq1oR0pvj+/Fo5prPbQyYu 6QXIWRyCt4MoNc1xDd7OixgsUln6w0f5t5vPoVZZVD7gWYB8AevgTBF+KjwxE4f8yPYs H5W2wAcP+V35LX86dTqXMl1UR69yvOjHyH3sy7CXTQi6wEy2F1UN8e3anpbxjBnVEu5R 8gF+rP1g9xpIn9kxPkY5chFkY7Q0MGJtsi5uC7Lp+zAF0iGmYhxKoB1M8A9ya1byTh46 blwQ== X-Gm-Message-State: ACgBeo2pp14LDFI+5q60jYixUonUwRv3q2nSpeixSi4+aAS2A2sBqfyz DY6ox6/s4hhA0VL/+ciQZuaQ7CkluNg5vaF2abzPvGCMsub0OQ== X-Received: by 2002:a05:6102:304e:b0:397:6b53:5f81 with SMTP id w14-20020a056102304e00b003976b535f81mr360723vsa.80.1662511679176; Tue, 06 Sep 2022 17:47:59 -0700 (PDT) MIME-Version: 1.0 References: <20220516214005.GQ76023@worktop.programming.kicks-ass.net> <20220518012429.4zqzarvwsraxivux@treble> <20220518074152.GB10117@worktop.programming.kicks-ass.net> <20220518173604.7gcrjjum6fo2m2ub@treble> In-Reply-To: From: Sami Tolvanen Date: Tue, 6 Sep 2022 17:47:23 -0700 Message-ID: Subject: Re: [PATCH] objtool: Fix symbol creation To: Peter Zijlstra , Josh Poimboeuf Cc: Nathan Chancellor , Nick Desaulniers , llvm@lists.linux.dev, LKML , kasan-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 18, 2022 at 3:10 PM Peter Zijlstra wrote: > > On Wed, May 18, 2022 at 10:36:04AM -0700, Josh Poimboeuf wrote: > > On Wed, May 18, 2022 at 09:41:52AM +0200, Peter Zijlstra wrote: > > > +static int elf_update_symbol(struct elf *elf, struct section *symtab, > > > + struct section *symtab_shndx, struct symbol *sym) > > > { > > > - Elf_Data *data, *shndx_data = NULL; > > > - Elf32_Word first_non_local; > > > - struct symbol *sym; > > > - Elf_Scn *s; > > > - > > > - first_non_local = symtab->sh.sh_info; > > > - > > > - sym = find_symbol_by_index(elf, first_non_local); > > > - if (!sym) { > > > - WARN("no non-local symbols !?"); > > > - return first_non_local; > > > - } > > > + Elf_Data *symtab_data = NULL, *shndx_data = NULL; > > > + Elf64_Xword entsize = symtab->sh.sh_entsize; > > > + Elf32_Word shndx = sym->sec->idx; > > > > So if it's a global UNDEF symbol then I think 'sym->sec' can be NULL and > > this blows up? > > Oh indeed, sym->sec ? sym->sec->idx : SHN_UNDEF it is. elf_update_symbol seems to be a bit broken even after this. I noticed it converts SHN_ABS symbols into SHN_UNDEF, which breaks some KCFI builds. In fact, the function drops all the special st_shndx values except SHN_XINDEX. Specifically, read_symbols sets sym->sec to find_section_by_index(elf, 0) for all SHN_UNDEF and special st_shndx symbols, which means sym->sec is non-NULL and sym->sec->idx is always 0 (= SHN_UNDEF) for these symbols. As elf_update_symbol doesn't look at the actual st_shndx value, it ends up marking the symbols undefined. This quick hack fixes the issue for me, but I'm not sure if it's the cleanest solution. Any thoughts? diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index c25e957c1e52..7e24b09b1163 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -619,6 +619,11 @@ static int elf_update_symbol(struct elf *elf, struct section *symtab, Elf64_Xword entsize = symtab->sh.sh_entsize; int max_idx, idx = sym->idx; Elf_Scn *s, *t = NULL; + bool is_special_shndx = sym->sym.st_shndx >= SHN_LORESERVE && + sym->sym.st_shndx != SHN_XINDEX; + + if (is_special_shndx) + shndx = sym->sym.st_shndx; s = elf_getscn(elf->elf, symtab->idx); if (!s) { @@ -704,7 +709,7 @@ static int elf_update_symbol(struct elf *elf, struct section *symtab, } /* setup extended section index magic and write the symbol */ - if (shndx >= SHN_UNDEF && shndx < SHN_LORESERVE) { + if ((shndx >= SHN_UNDEF && shndx < SHN_LORESERVE) || is_special_shndx) { sym->sym.st_shndx = shndx; if (!shndx_data) shndx = 0; Sami