This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]