From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25866 invoked by alias); 17 Sep 2018 15:07:51 -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 25843 invoked by uid 89); 17 Sep 2018 15:07:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=serious, silicon, Hx-languages-length:997 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Sep 2018 15:07:49 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E86E32B68D; Mon, 17 Sep 2018 15:07:47 +0000 (UTC) Received: from [10.36.116.222] (ovpn-116-222.ams2.redhat.com [10.36.116.222]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 87448106A7B2; Mon, 17 Sep 2018 15:07:45 +0000 (UTC) To: Stafford Horne , binutils@sourceware.org Cc: GDB patches , Richard Henderson , Openrisc References: <20180821143823.16985-1-shorne@gmail.com> <20180908213515.GN4594@lianli.shorne-pla.net> From: Nick Clifton Openpgp: preference=signencrypt Subject: Re: [PATCH 0/4] OpenRISC binutils updates and new relocs Message-ID: Date: Mon, 17 Sep 2018 15:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180908213515.GN4594@lianli.shorne-pla.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-09/txt/msg00580.txt.bz2 Hi Stafford, > Does anyone have concerns with these patches? Mostly they are for openrisc > parts only. Sorry for the long silence - I have been very busy of late. The patch series looks basically fine to me, so I have no concerns there. There are a few minor formatting glitches, but nothing serious. 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). 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 ? Cheers Nick