From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128145 invoked by alias); 17 Sep 2018 16:29:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 128112 invoked by uid 89); 17 Sep 2018 16:29:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=H*Ad:U*rth, HX-Received:2354, HX-Received:sk:u20-v6m, Hx-spam-relays-external:209.85.210.195 X-HELO: mail-pf1-f195.google.com Received: from mail-pf1-f195.google.com (HELO mail-pf1-f195.google.com) (209.85.210.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Sep 2018 16:29:39 +0000 Received: by mail-pf1-f195.google.com with SMTP id k21-v6so7800025pff.11; Mon, 17 Sep 2018 09:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TLXhgvFezzB8w7AUlh97U/MiUUQKno9zQAbNBSTNZwQ=; b=tbkmSzXK6NebfPuMZmV1r7+n/dteRw/O48wmUp/0DKkbTb9WCBcO6lg9t7NL3JT+56 qM023ALX7cAoQR/XxhjcGzjbZqWm71QSJmXgpoxDrM5mXuaKAZOAiikKGJqJd0djltGi hrNRxBgXYEkwTWjV+SMLRAoa6Qj47vATiC36ugFMjaTDjyYgF9XXJJ4wkwZ1evAmLklY efHLMtheLvLBQ4krWFPYuW8eQaGkiEsm1svtV9NOvwHMFG2mGknqgUx/2E41xEZjVFQY a/ziqcw0xel0ADfO2nN8e44kttzHQnvlReJtQ+DOPB3YK8SAPaBFBWj6U27bgzDOGUa6 YkAQ== Return-Path: Received: from cloudburst.twiddle.net ([209.121.128.187]) by smtp.googlemail.com with ESMTPSA id o10-v6sm31938114pfk.76.2018.09.17.09.29.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Sep 2018 09:29:30 -0700 (PDT) Sender: Richard Henderson Subject: Re: [PATCH 0/4] OpenRISC binutils updates and new relocs To: Nick Clifton , Stafford Horne , binutils@sourceware.org Cc: GDB patches , Openrisc References: <20180821143823.16985-1-shorne@gmail.com> <20180908213515.GN4594@lianli.shorne-pla.net> From: Richard Henderson Openpgp: preference=signencrypt Message-ID: <0aad2c15-5329-1d01-028f-2e9fcb14a783@twiddle.net> Date: Mon, 17 Sep 2018 16:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00583.txt.bz2 On 9/17/18 8:07 AM, Nick Clifton wrote: > I do not see any need to add extra document for the new relocs, unless you > have created new assembler pseudo-ops to generate them. (I did not see any > code to add such operators, but I may have missed something). There is new syntax for these new relocs, in the form of function-like markup. E.g: l.ori r3,r4,@lo(foo) # an existing reloc l.ori r3,r4,@po(foo) # a new reloc added here > I do have one question though. Is there a need to be able to distinguish > between binaries that use the new l.adrp instruction and those that don't. > For example if a library is built using the new instruction but then it is > linked into an executable which is supposed to run on silicon which does > not support the new instruction, should the linker issue an error ? If so, > how does it detect this situation ? I have never been a fan of how this is handled e.g. for mips. To that end, I have done nothing at all. This is more in line with how we (do not) handle this situation for x86. r~