Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3438362pxj; Mon, 7 Jun 2021 10:34:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzSXZ8bu5gHg+8sLBhL80lbEMUGVCnHosHrN38Ur2mGszu7+0QmAfpCj/yB6dFGkI8Hr4w X-Received: by 2002:a17:906:70d4:: with SMTP id g20mr6233220ejk.327.1623087260318; Mon, 07 Jun 2021 10:34:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623087260; cv=none; d=google.com; s=arc-20160816; b=wIKlh2lxaBidyv0fCRKbE+m0bBbqyhwP3/Z3I7nBIggg4CPbWrT23eaNhBHL9fyDq3 N7Z3bTZ+cdl9YIj58Goh8L15L2yqvR9dlNy0G0lLMVjBVyXvTxhc7B53Ta5snBOEOR3i 1VqYM+XdOBxXeE97ehTSaMQVxsU35GNwv/YyCmNuHPng8aFSEBPpqrBMJhH5sEXp4rfi qev7ZLisGo+bOoEx6CM2qOr3aGjj82WXHfZTBf0iBY65XhOb4+/f9B0cAWziAT2LKKLs m1FFXFE2FNw+ZvY4X8FTu6yylD0yrCJPj75BOrdw40SS0kFigyXFuHTLAbNiAAs+a88p PYLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=BQu5pNPG2dh6x4sehCqhIbiMNqsJJY7tUz3xTsUBu14=; b=wjphOE+TBnAaTHuFlOrOrrO+4rCHGgqOjbCp+cN4ZMIJWx9xKvdVsSbWGP8TljAkcd BHW4OiYPisf0V7PAEwbfYNa1gGgCHOw1Rg7Tv4/6KDCuIWB6m3zt00WW28/VdQM2IyT5 mVv/olQEB61BBLdLZ5Yyvb91ixMdxMO00mzIhZhRb1gRo+VApZVYkpW+px2lFZzA/GAB n3+d0kxjDrqZmDqUYHB6PeTLR6o8T5UraqGSLtMhtOYpPbD/DynrocPrb2R+XR54QC2J x9NKmaseQoHPUS3R6ZEeeV5fC0Nnl1uG4v6hwnJWudf616ZpitTr14tPmzCptxgMoXYG n7vA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y13si12998601ejk.111.2021.06.07.10.33.56; Mon, 07 Jun 2021 10:34:20 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230475AbhFGRdg (ORCPT + 99 others); Mon, 7 Jun 2021 13:33:36 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:59119 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S230313AbhFGRdf (ORCPT ); Mon, 7 Jun 2021 13:33:35 -0400 X-UUID: a43f5ae8677e46038e81b1f0862970a9-20210608 X-UUID: a43f5ae8677e46038e81b1f0862970a9-20210608 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1385272531; Tue, 08 Jun 2021 01:31:39 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs08n2.mediatek.inc (172.21.101.56) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 8 Jun 2021 01:31:38 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 8 Jun 2021 01:31:38 +0800 From: Mark-PK Tsai To: CC: , , , , , , , , , , , Subject: Re: [PATCH] recordmcount: avoid using ABS symbol as reference Date: Tue, 8 Jun 2021 01:31:38 +0800 Message-ID: <20210607173138.3882-1-mark-pk.tsai@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20210607094433.473100d9@oasis.local.home> References: <20210607094433.473100d9@oasis.local.home> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Mon, 7 Jun 2021 13:44:21 +0200 > Peter Zijlstra wrote: > > > There's an extended section header index section for just that. And > > recordmcount actually seems to use that as well. > > > > I can't seem to find enough of the thread to figure out what the actual > > problem is though. The lore archive doesn't have anything prior to this > > message. > > > > One should only use st_shndx when >SHN_UDEF and > SHN_XINDEX, then use .symtab_shndx. > > > > Apparently you've found a case where neither is true? In that case > > objtool seems to use shndx 0. A matching recordmcount patch would be > > something like this. Hi Peter, Should I resend the below patch as v2? > > Mark-PK, > > Does the below patch fix it for you too (if you backport it to your > kernel). I much rather have recordmcount match objtool, as one day the > two will hopefully merge to one executable. > > -- Steve > Yes, this patch fix it. > > > > > > > diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h > > index f9b19524da11..d99cc0aed6fe 100644 > > --- a/scripts/recordmcount.h > > +++ b/scripts/recordmcount.h > > @@ -194,13 +194,18 @@ static unsigned int get_symindex(Elf_Sym const *sym, Elf32_Word const *symtab, > > unsigned long offset; > > int index; > > > > - if (sym->st_shndx != SHN_XINDEX) > > + if (sym->st_shndx > SHN_UDEF && > > + sym->st_shndx < SHN_LORESERVE) > > return w2(sym->st_shndx); > > > > - offset = (unsigned long)sym - (unsigned long)symtab; > > - index = offset / sizeof(*sym); > > + if (sym->st_shndx == SHN_XINDEX) { > > + offset = (unsigned long)sym - (unsigned long)symtab; > > + index = offset / sizeof(*sym); > > > > - return w(symtab_shndx[index]); > > + return w(symtab_shndx[index]); > > + } > > + > > + return 0; > > } > > > > static unsigned int get_shnum(Elf_Ehdr const *ehdr, Elf_Shdr const *shdr0)