From: Tom Tromey <tom@tromey.com>
To: Peeter Joot <peeter.joot@gmail.com>
Cc: gdb-patches@sourceware.org, peeter.joot@lzlabs.com, simark@simark.ca
Subject: Re: [PATCH] review request: implementing DW_AT_endianity
Date: Thu, 22 Feb 2018 17:20:00 -0000 [thread overview]
Message-ID: <87371tq6uz.fsf@tromey.com> (raw)
In-Reply-To: <20171010233010.58471-1-peeter.joot@lzlabs.com> (Peeter Joot's message of "Tue, 10 Oct 2017 19:30:10 -0400")
>>>>> "Peeter" == Peeter Joot <peeter.joot@gmail.com> writes:
I happened to run across this patch today.
What's the status of it?
Peeter> +enum bfd_endian
Peeter> +type_byte_order (struct gdbarch * gdbarch, struct type *type)
Peeter> +{
Peeter> + if (TYPE_ENDIANITY_BIG (type))
Peeter> + return BFD_ENDIAN_BIG;
Peeter> + else if (TYPE_ENDIANITY_LITTLE (type))
Peeter> + return BFD_ENDIAN_LITTLE;
Peeter> + if (!gdbarch)
Peeter> + gdbarch = get_type_arch (type);
Peeter> + return gdbarch_byte_order (gdbarch);
Does it ever make sense to call type_byte_order with a gdbarch other
than the type's gdbarch? I would assume not but I'm not really sure.
What would this mean?
Anyway, if it doesn't make sense, then I'd suggest just removing the
gdbarch parameter.
Peeter> + unsigned int flag_endianity_big : 1;
Peeter> + unsigned int flag_endianity_little : 1;
It also seems to me that perhaps only a single bit is needed --
something like:
unsigned int flag_endian_differs_from_arch : 1;
Then type_byte_order could do:
enum bfd_endian endian = gdbarch_byte_order (...);
if (blah blah flag_endian_differs_from_arch)
endian = (endian == BFD_ENDIAN_LITTLE) ? BFD_ENDIAN_BIG : BFD_ENDIAN_LITTLE;
Of course this only makes sense if the arch endianness can't change
somehow, and if only the type's arch can be used to get the endianness.
Tom
next prev parent reply other threads:[~2018-02-22 17:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-06 15:06 Peeter Joot
2017-10-06 21:18 ` Peeter Joot
2017-10-08 18:41 ` Simon Marchi
2017-10-09 9:11 ` Peeter Joot
2017-10-09 12:12 ` Simon Marchi
2017-10-10 18:16 ` Peeter Joot
2017-10-10 18:33 ` Simon Marchi
2017-10-10 18:38 ` Peeter Joot
2017-10-10 18:48 ` Simon Marchi
2017-10-10 19:38 ` Peeter Joot
2017-10-10 23:30 ` [PATCH] " Peeter Joot
2017-10-11 2:29 ` Peeter Joot
2017-10-12 20:23 ` Simon Marchi
2018-02-22 17:20 ` Tom Tromey [this message]
2018-02-22 17:39 ` Peeter Joot
2019-02-13 13:12 ` Tom Tromey
2019-02-13 14:11 ` Peeter Joot
2019-02-13 14:47 ` Pedro Alves
2019-02-13 16:19 ` Pedro Alves
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=87371tq6uz.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=peeter.joot@gmail.com \
--cc=peeter.joot@lzlabs.com \
--cc=simark@simark.ca \
/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