This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/7] Move some integer operations to common.
- From: Doug Evans <dje at google dot com>
- To: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Gary Benson <gbenson at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 22 Sep 2015 09:05:57 -0700
- Subject: Re: [PATCH 2/7] Move some integer operations to common.
- Authentication-results: sourceware.org; auth=none
- References: <1441973603-15247-1-git-send-email-antoine dot tremblay at ericsson dot com> <1441973603-15247-3-git-send-email-antoine dot tremblay at ericsson dot com> <20150911142442 dot GA23515 at blade dot nx> <55F30C55 dot 3080507 at ericsson dot com> <55F31019 dot 1080607 at ericsson dot com> <20150914092453 dot GA26894 at blade dot nx> <55F6E5BC dot 7050006 at ericsson dot com> <20150921091007 dot GA23767 at blade dot nx> <55FFCAF2 dot 5040400 at redhat dot com> <56004326 dot 50507 at ericsson dot com>
On Mon, Sep 21, 2015 at 10:49 AM, Antoine Tremblay
<antoine.tremblay@ericsson.com> 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]