From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92440 invoked by alias); 19 Feb 2020 16:48:39 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 92400 invoked by uid 89); 19 Feb 2020 16:48:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=brew, transit, H*Ad:U*nickc, practices X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 16:48:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582130912; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=U5qN3Is25u6xMNL0uPym9cmfDb/CJRBQoyNGnYYpJ2I=; b=XojivqA6jTnS8ejQkoql6QyxnTrJHisIZA+p7kuDhs+xack+ZYZEDqhLpJIOvMlI4BYw+C JPgKm6d0QkHaIE9JBw5s5hHOtsBC/qBNR8ObcuT1NCreRyrdV2u+cmLcrPzzi97lcTgh70 dGaUmcSrbeW2XCOSr2bhUHxMWxrutPU= 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-290-zrAEu8rxP9ysHk7pF7jA9A-1; Wed, 19 Feb 2020 11:48:30 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9C46D100550E; Wed, 19 Feb 2020 16:48:29 +0000 (UTC) Received: from [10.36.116.228] (ovpn-116-228.ams2.redhat.com [10.36.116.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E42AD5C3FA; Wed, 19 Feb 2020 16:48:28 +0000 (UTC) To: Alan Modra Cc: binutils@sourceware.org References: <877e0pmpew.fsf@redhat.com> <20200218002019.GD5570@bubble.grove.modra.org> From: Nick Clifton Subject: Re: RFC: Supporting multiple relocs per section Message-ID: <20d172e0-b5b1-8323-f04c-b5cf7543e5d9@redhat.com> Date: Wed, 19 Feb 2020 16:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200218002019.GD5570@bubble.grove.modra.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00474.txt.bz2 Hi Alan, >> As part of this process I also discovered that the BFD library would >> unconditionally convert OS-specific and PROC-specific section indices >> into SHN_ABS indices when writing out symbol tables, > That sounds like a bug that should be fixed for all ELF targets and > not via a target hook. A good point - I will do that. >> [1] This is to support kernel live patch modules used by Fedora and RHEL >> and possibly other distributions too. >=20 > Can the need for multiple reloc sections be avoided? Or at least > any processing on extra reloc sections?=20 Not now. The scheme has been in place for a couple of years now, so I think that it is too late to change it. > The current support as such > for multiple reloc sections in bfd is by treating any extra reloc > sections as normal sections, ie. just a blob of data in the section. > Or at least that is what is supposed to happen. I thought so too, but it turns out not to be so. The extra reloc=20 sections are dropped, rather than being preserved in transit from input to output. =20 > Hmm, I see your patch updates reloc symbols in the extra reloc > sections. Am I correct in guessing that the underlying problem is > that objcopy/strip renumber symbols? Yup. :-) > And I suppose there isn't any > way to convince people not to objcopy/strip files with extra reloc > sections?=20 No. The actual issue came about because the kernel team are trying to update their practices and rather than create and distribute these live update modules by hand they are now trying to use the brew/koji build systems. Which use objcopy and strip from the binutils. Which corrupts the modules... > What about requiring those extra reloc sections only have > relocs using a zero symbol index? No, they need specific symbol indicies in order for the relocations to be applied by the kernel's live patcher... Cheers Nick =20