From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89220 invoked by alias); 22 Sep 2015 17:50:36 -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 88048 invoked by uid 89); 22 Sep 2015 17:50:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg21.ericsson.net Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 22 Sep 2015 17:50:34 +0000 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 53.27.26730.BA921065; Tue, 22 Sep 2015 12:12:59 +0200 (CEST) Received: from [142.133.110.95] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.92) with Microsoft SMTP Server id 14.3.248.2; Tue, 22 Sep 2015 13:50:31 -0400 Subject: Re: [PATCH 2/7] Move some integer operations to common. To: Doug Evans References: <1441973603-15247-1-git-send-email-antoine.tremblay@ericsson.com> <1441973603-15247-3-git-send-email-antoine.tremblay@ericsson.com> <20150911142442.GA23515@blade.nx> <55F30C55.3080507@ericsson.com> <55F31019.1080607@ericsson.com> <20150914092453.GA26894@blade.nx> <55F6E5BC.7050006@ericsson.com> <20150921091007.GA23767@blade.nx> <55FFCAF2.5040400@redhat.com> <56004326.50507@ericsson.com> CC: Pedro Alves , Gary Benson , gdb-patches From: Antoine Tremblay Message-ID: <560194E7.1070203@ericsson.com> Date: Tue, 22 Sep 2015 17:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00535.txt.bz2 On 09/22/2015 12:05 PM, Doug Evans wrote: > On Mon, Sep 21, 2015 at 10:49 AM, Antoine Tremblay > wrote: >> >> >> On 09/21/2015 05:16 AM, Pedro Alves wrote: >>> >>> On 09/21/2015 10:10 AM, Gary Benson wrote: >>>> >>>> Hi Antoine, Pedro, >>>> >>>> Antoine Tremblay wrote: >>> >>> >>>>> So I've made bfd.h a requirement of GDBServer, and when there will >>>>> be a libgdbcommon we can have the whole lib as a requirement there. >>>>> >>>>> See patch v2 in next mail... >>>> >>>> >>>> I don't think this will be acceptable. If I understand correctly, >>>> gdbserver supports some platforms that GDB (and BFD) does not, and >>>> this patch would prevent gdbserver being built on those platforms. >>>> Even if I'm wrong here, I've previously found it useful to build >>>> gdbserver alone, and I think this would break that too. >>>> >>>> Pedro knows more about these kinds of setups, I've copied him in. >>>> >>> >>> (Without looking at the patch in detail), >>> >>> Gary's right. bfd.h is a generated file, generated at bfd build time. >>> Anton, try building only gdbserver in a clean directory, >>> separate from gdb, and it will fail with your patch. >>> >> Ok I was worried this would not work.. >> >> I've removed much of the endianness dependencies from my patchset but I >> still have a dependency on the bfd endiannness enum to share code with GDB's >> read_memory_unsigned_integer. >> >> So I will do a wrapper around read_memory_unsigned_integer in GDB that takes >> an int and transfers it to the real read_memory_unsigned_integer as the >> proper enum (by implicit conversion). And use an int when referring to the >> enum in shared code. >> >> Unless there's an objection to this method ? > > I'd rather not discard the enum. > Yes me too, that's why I had these previous solutions. > The first question I have is: where do we want to be in the long term? > I totally support moving more and more application independent code > into application independent places. > It's really a shame that something as simple as this is getting in the way. > > [Ideally, I'd also like to remove bfd dependencies wherever possible, > but that can be a bit problematic. So I'm setting aside this > possibility. E.g., using an enum without bfd in the name.] > To me this sounds like a case by case basis, you can't move to application independent code without accepting to import some dependencies from the applications or removing those dependencies. So it seems not easy to me to set a future direction to this kind of balance. But I'm still new to GDB, I'm sure others may have more ideas on this. > The next question I have is: Is there anything in what we need that > needs to be in a generated header? > Can we ask the bfd folks to move things like bfd_endian to a > non-generated header? > [bfd.h can still include it] > Quickly looking at how bfd.h is done it seems to be possible to move some stuff to a static file however I wonder if the current problem would prove enough justification for that work. It would also introduce a bfd version dependency in common code to check for this static header. And it could be quite an ugly #ifdef changing ints to enum in case the header is present. One thing to consider too is that this patchset has now changed a bit and this enum is no longer used in GDBServer itself at all. Since the enum is only used in GDB's context and that the common code is only a carrier for this context, this is not a risk type wise. It's also not a risk for C++ conversion, as this is a pure C enum that won't be converted to C++ unless bfd is which I doubt may happen ? It could also be possible to require a make headers in bfd to build GDBServer and possibly make that more convenient in the Makefile ? I'm not sure it's worth it as long as GDBServer doesn't use the enum itself, however I'm curious if others would find that acceptable.