Re: [PATCH 2/7] Move some integer operations to common.

[Doug Evans <dje@google.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]