This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 2/7] Move some integer operations to common.
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Doug Evans <dje at google 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 13:50:31 -0400
- 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> <CADPb22TMVBzejDjtWr6VRvmtkfzVJpSTtuetMdTLiJaf6i2W_A at mail dot gmail dot com>
On 09/22/2015 12:05 PM, Doug Evans wrote:
On Mon, Sep 21, 2015 at 10:49 AM, Antoine Tremblay
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
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
[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.