Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp545626ybm; Thu, 28 May 2020 09:05:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMzGXoyE78hDcPTr2RIhu8n53RswRJ2gJk3GVRTY3rULi54/V2ixEv/rUDIh+vK0iAW0PC X-Received: by 2002:a17:906:b88c:: with SMTP id hb12mr3481189ejb.483.1590681931119; Thu, 28 May 2020 09:05:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590681931; cv=none; d=google.com; s=arc-20160816; b=aWzIjMKEu4arEz8S3lJSPv+wK8w1zXdSKEZtQOkDcsIoIfeoOyCjlgdgZ6jFOSqtLk o3Dc+sdSWDTpfBDaDeEerH58nAD4qEUZXI98/3ElEUB62Aq5y3tHl/AvR42CcjQuWICV pchvzjwyJCeZkDTD2BTg3Pi/oAnDsR7dOxsWpbVWeYCtx8dIUra23fdBUdlbP8lbm/b2 9ah8lax6GFmA93DkORi7aji3MTg4xCHV7dnwmmZO7U+PXS11xFrX401nq5iCvp4wLu2I 5ZHLL0FO4taUxv3hoWzkqeynOdycCVq96moR2xnfLgD+RnD9S5yH94NjeeQSkMz4SIoL aCQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date; bh=VR3zyRuBp3lt46JxpqNGOz7oTnO5WomOtBq4zwU3uGc=; b=pNoZgJy1GTHhju13tPOU7BsWlUku3O5Jlp681TaqsRlrkmE4JIL2uk4Ah6YqbXdEbz R2osAYls8OfzPhZxC/ZX1iTUK8NxOW5GE0JbNUrdA+EL3JMcpRCG0WQXrjt7JgZN3VeD iu2YmOCDkV7LRhkkmseglQafOsJoDCPuFpvg64zgzlcEe+oNsLnCwHGLruWCfFSLtq4x eAnONZDGqgy3qQ5JIktmKahm3MFYPS5QoS+itkxv4lRGX5fDnoYiBscAnMXWdfCR3KCC DlYAY8679k1fKeRpQofqCn8aetUHZqRtIPsU07IrplFhdwuuBFcnaDAm0TSiDAe4vlYz ar0g== 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=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ai4si4155465ejc.704.2020.05.28.09.05.06; Thu, 28 May 2020 09:05:31 -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=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404731AbgE1QCt (ORCPT + 99 others); Thu, 28 May 2020 12:02:49 -0400 Received: from ex13-edg-ou-002.vmware.com ([208.91.0.190]:32307 "EHLO EX13-EDG-OU-002.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404631AbgE1QCs (ORCPT ); Thu, 28 May 2020 12:02:48 -0400 Received: from sc9-mailhost2.vmware.com (10.113.161.72) by EX13-EDG-OU-002.vmware.com (10.113.208.156) with Microsoft SMTP Server id 15.0.1156.6; Thu, 28 May 2020 09:02:43 -0700 Received: from localhost (unknown [10.200.192.41]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 69495B2092; Thu, 28 May 2020 12:02:47 -0400 (EDT) Date: Thu, 28 May 2020 09:02:47 -0700 From: Matt Helsley To: Josh Poimboeuf CC: , Peter Zijlstra , Steven Rostedt Subject: Re: [RFC][PATCH 2/3] objtool: Find relocation base section using sh_info Message-ID: <20200528160247.GW9040@rlwimi.vmware.com> Mail-Followup-To: Matt Helsley , Josh Poimboeuf , linux-kernel@vger.kernel.org, Peter Zijlstra , Steven Rostedt References: <20200528140916.6crguzfpehf6lext@treble> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200528140916.6crguzfpehf6lext@treble> Received-SPF: None (EX13-EDG-OU-002.vmware.com: mhelsley@vmware.com does not designate permitted sender hosts) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2020 at 09:09:16AM -0500, Josh Poimboeuf wrote: > On Wed, May 27, 2020 at 09:42:32AM -0700, Matt Helsley wrote: > > Currently objtool uses a naming heuristic to find the "base" > > section to apply the relocation(s) to. The standard defines > > the SHF_INFO_LINK flag (SHF => in the section header flags) > > which indicates when the section header's sh_info field can > > be used to find the necessary section. > > > > Warns when the heuristic is used as a fallback and changes > > the name heuristic calculation to handle rela (explicit > > addend) and now rel (implicit addend) relocations. > > Does this fallback case actually happen? Not that I could see. I was thinking about taking it out but I haven't tried this set with clang or other toolchains. So I was wondering if you think holding off before removing it would be wise or if you'd rather just remove it. Cheers, -Matt Helsley