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.

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,
but whatever.

 > 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.

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