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

[Antoine Tremblay <antoine.tremblay@ericsson.com>]

On 09/22/2015 12:05 PM, Doug Evans wrote:
> 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.
>
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.