Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] tilegx-tdep: Correct aliasing errors in `tilegx_analyze_prologue'
Date: Tue, 18 Oct 2016 09:22:00 -0000	[thread overview]
Message-ID: <14cb784b-8e4e-572a-7377-21af868510d1@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1610171706410.31859@tp.orcam.me.uk>

On 10/18/2016 04:50 AM, Maciej W. Rozycki wrote:
>> > 
>> > Sure, please do ahead.
>> > 
>> > I'd be better if tilegx.h used uint32_t/uint64_t, etc,
>> > but that can always be done separately by someone motivated.

>  The issue there is `tilegx.h' is shared with binutils which have not yet 
> moved past C89 I believe.  Of course the use of `long long' is already 
> non-C89, however it's been there with some C89 compilers before `stdint.h' 
> types have been introduced.  We could use `bfd_uint64_t' instead, but that 
> would make `tilegx.h' depend on a BFD header.  So it's not an obvious call 
> and therefore I agree it's best left to someone who has an actual interest 
> with the target.

Yeah, C89 on paper.  :-)  It's certainly fine to use unadorned uint64_t etc.
directly nowadays.  Even if the host compiler is so old that it doesn't
support those, we have "bfd_stdint.h" to fill the gap:

 opcodes/aarch64-dis.h:23:#include "bfd_stdint.h"
 opcodes/nds32-dis.c:30:#include "bfd_stdint.h"
 opcodes/aarch64-dis.c:22:#include "bfd_stdint.h"
 ld/elf-hints-local.h:28:#include "bfd_stdint.h"

Something like 'grep "u\?int\(8\|16\|32\|64\)_t" -rn'
will show many uses of uint32_t, etc. (not bfd_uint*_t) throughout
opcodes, bfd, ld, etc.  I won't be surprised at all if someone
missed adding bfd_stdint.h for some of them and they've been
working in practice for a long while.

(better than bfd_stdint.h would be to use gnulib for the whole
toolchain, not just for gdb, but that's yet another matter.)

As I've been suggesting in recent C++11 discussions,
IMO, what we claim to support in theory matters significantly
less than what we actually support in practice.  And in
practice, all it matters is which compilers (and their versions),
not standards, people care about actually using and supporting.
Standards give us guidelines, not final answers.

>  Committed now, thanks for your review.

Thanks.

Thanks,
Pedro Alves


      reply	other threads:[~2016-10-18  9:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 15:18 Maciej W. Rozycki
2016-10-17 15:46 ` Pedro Alves
2016-10-18  3:50   ` Maciej W. Rozycki
2016-10-18  9:22     ` Pedro Alves [this message]

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=14cb784b-8e4e-572a-7377-21af868510d1@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@imgtec.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