This is the mail archive of the
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: Wed, 23 Sep 2015 20:40:48 +0000
- Subject: Re: [PATCH 2/7] Move some integer operations to common.
- Authentication-results: sourceware.org; auth=none
Antoine Tremblay writes:
> > 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.
One would hope no one would try to set too high a bar to justify this 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.
This is a non-issue. gdb always uses bfd HEAD, and in general
we don't support uses of bfd outside of binutils and gdb.
> 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.
I'm less interested in whether the enum is used in gdbserver than
whether it is used in the common code (and thus by extension
it still matters what gdbserver uses).
We *could* just use a bool, is_big_endian or is_little_endian.
The code today assumes it never sees BFD_ENDIAN_UNKNOWN,
which would be nice to fix.
Or we could invent a new enum that just has big/little endian.