From: Doug Evans <dje@google.com>
To: Antoine Tremblay <antoine.tremblay@ericsson.com>
Cc: Pedro Alves <palves@redhat.com>, Gary Benson <gbenson@redhat.com>,
gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/7] Move some integer operations to common.
Date: Wed, 23 Sep 2015 20:40:00 -0000 [thread overview]
Message-ID: <001a113448083110dd05207021ae@google.com> (raw)
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.
next reply other threads:[~2015-09-23 20:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-23 20:40 Doug Evans [this message]
2015-09-24 11:53 ` Antoine Tremblay
-- strict thread matches above, loose matches on Subject: below --
2015-09-11 12:13 [PATCH 0/7] Support tracepoints and software breakpoints on ARM aarch32-linux in GDBServer Antoine Tremblay
2015-09-11 12:13 ` [PATCH 2/7] Move some integer operations to common Antoine Tremblay
2015-09-11 14:24 ` Gary Benson
2015-09-11 17:16 ` Antoine Tremblay
2015-09-11 17:32 ` Antoine Tremblay
2015-09-14 9:24 ` Gary Benson
2015-09-14 15:20 ` Antoine Tremblay
2015-09-21 9:10 ` Gary Benson
2015-09-21 9:16 ` Pedro Alves
2015-09-21 17:49 ` Antoine Tremblay
2015-09-22 16:06 ` Doug Evans
2015-09-22 17:50 ` Antoine Tremblay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=001a113448083110dd05207021ae@google.com \
--to=dje@google.com \
--cc=antoine.tremblay@ericsson.com \
--cc=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).