From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22478 invoked by alias); 22 Sep 2015 16:06: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 22468 invoked by uid 89); 22 Sep 2015 16:06:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f175.google.com Received: from mail-ig0-f175.google.com (HELO mail-ig0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 22 Sep 2015 16:06:39 +0000 Received: by igbkq10 with SMTP id kq10so102457197igb.0 for ; Tue, 22 Sep 2015 09:06:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VOCwZBVP8D24Z/x59ywYWXp4+43vIdm/ChhJew5MLyo=; b=VPtZJ/8AcVYdYDadpEUslpS0fhcfPCc/zv3wrEzAf5lk57R9iSXAcgE58ARvMCS6mz k1Qbvx4p2icMoTXZ3z+2o/NGEDm6ebKOJOh8zvHJLmqHdOtYCLy46vjZQ/CKHPQSD+8E NaYjQmJfS2RXEkr91hW7FWB18V7Mb9wWE2L9YIzxrRwcRtMVYNLN9PB3rmqwaNkDXROP wewW7tYbBYgPXkwKkyq0vbsFXGGXtj+LK3VSW7hL68Edx/w7TgFfFyTsoax76AEeMGXV T9h8IgFS9qfDgNw6GjVWTVeNRrLtahH3VSNj9Sw6GZeNoOwW8BivsmwOInfpNhE4Xf2B t9kw== X-Gm-Message-State: ALoCoQlUdc1lylA3Ac2786pCFhqi4DxLDsFl6mBN+Lw96s9Nitovo/3Drfu6pAps+IkSQyVpLQCW X-Received: by 10.50.79.196 with SMTP id l4mr17056581igx.48.1442937997492; Tue, 22 Sep 2015 09:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.19.130 with HTTP; Tue, 22 Sep 2015 09:05:57 -0700 (PDT) In-Reply-To: <56004326.50507@ericsson.com> 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> From: Doug Evans Date: Tue, 22 Sep 2015 16:06:00 -0000 Message-ID: Subject: Re: [PATCH 2/7] Move some integer operations to common. To: Antoine Tremblay Cc: Pedro Alves , Gary Benson , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00528.txt.bz2 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. 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.] 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]