This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] review request: implementing DW_AT_endianity
- From: Tom Tromey <tom at tromey dot com>
- To: Peeter Joot <peeter dot joot at gmail dot com>
- Cc: gdb-patches at sourceware dot org, peeter dot joot at lzlabs dot com, simark at simark dot ca
- Date: Thu, 22 Feb 2018 10:20:04 -0700
- Subject: Re: [PATCH] review request: implementing DW_AT_endianity
- Authentication-results: sourceware.org; auth=none
- References: <VI1PR0501MB286163B3EC58E11776F29D2A9C750@VI1PR0501MB2861.eurprd05.prod.outlook.com> <20171010233010.58471-1-peeter.joot@lzlabs.com>
>>>>> "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