Issue with pointer types marked with scalar_storage_order

Issue with pointer types marked with scalar_storage_order

[Ulrich Weigand]

Hello,

for a few years now, GCC has supported the scalar_storage_order
attribute (and pragma) that allows specifying the storage order
(endianness) of structures.  This affects both the code GCC
generates to access variables declared using the attribute,
and also the debug info: GCC emits the DW_AT_endianity attribute
to allow debuggers to work correctly with those variables as well.

However, in one specific scenario this doesn't work correctly
right now: pointer types.  Currently, GCC *will* swap the storage
order for members of pointer type in a structure declared using
scalar_storage_order, but it will *not* emit DW_AT_endianity
for these fields -- and it really cannot, because the DWARF
standard allows DW_AT_endianity only for DW_TAG_base_type
type entries and not for DW_TAG_pointer_type entries.

I'm not really sure where exactly the bug is, because I'm not
quite sure if pointer types actually *should* be byte swapped.

On the one hand, the typical use case of scalar_storage_order
is to simplify accessing binary data (read from a file or the
network) that was generated on a "foreign" architecture that
uses a different byte order.  Those use cases are unlikely
to involve any pointer types, since pointer values from a
foreign system are typically not usable on the current
system anyway.

On the other hand, even the name of the attribute specifically
refers to *scalar* types, and the C standard does classsify
pointer types amongst the scalar type.  So maybe this was
originally intended?

If we do want to byte-swap pointer types, then I guess we need
to still fix the debug info problem, which I guess would at a
minimum require extending DWARF to allow DW_AT_endianity as an
attribute to DW_TAG_pointer_type (and then probably also
DW_TAG_reference_type, DW_TAG_rvalue_reference_type,
DW_TAG_ptr_to_member_type and possibly others).  Also, the
implementation in GDB would need to be changed accordingly.

Any comments or suggestions on what to do here?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Re: Issue with pointer types marked with scalar_storage_order

[Eric Botcazou]

> I'm not really sure where exactly the bug is, because I'm not
> quite sure if pointer types actually *should* be byte swapped.
> 
> On the one hand, the typical use case of scalar_storage_order
> is to simplify accessing binary data (read from a file or the
> network) that was generated on a "foreign" architecture that
> uses a different byte order.  Those use cases are unlikely
> to involve any pointer types, since pointer values from a
> foreign system are typically not usable on the current
> system anyway.
> 
> On the other hand, even the name of the attribute specifically
> refers to *scalar* types, and the C standard does classsify
> pointer types amongst the scalar type.  So maybe this was
> originally intended?

I don't think so, the feature was first implemented for Ada and, in Ada, 
pointer types (called access types) are *not* scalar types.  So this indeed 
looks like a small oversight in the implementation.

> Any comments or suggestions on what to do here?

I'm going to conduct some testing in Ada but, barring unexpected fallout, I 
would be in favor of changing the GCC implementation.  It's presumably a 1-
line change in the reverse_storage_order_for_component_p predicate.

-- 
Eric Botcazou

Re: Issue with pointer types marked with scalar_storage_order

[Ulrich Weigand]

On Thu, May 06, 2021 at 04:07:52PM +0200, Eric Botcazou wrote:
> > On the other hand, even the name of the attribute specifically
> > refers to *scalar* types, and the C standard does classsify
> > pointer types amongst the scalar type.  So maybe this was
> > originally intended?
> 
> I don't think so, the feature was first implemented for Ada and, in Ada, 
> pointer types (called access types) are *not* scalar types.  So this indeed 
> looks like a small oversight in the implementation.

Ah, I see.

> > Any comments or suggestions on what to do here?
> 
> I'm going to conduct some testing in Ada but, barring unexpected fallout, I 
> would be in favor of changing the GCC implementation.  It's presumably a 1-
> line change in the reverse_storage_order_for_component_p predicate.

Makes sense to me.  Thanks for the quick fix!

Tom Tromey wrote:
> Ulrich> If we do want to byte-swap pointer types, then I guess we need
> Ulrich> to still fix the debug info problem, which I guess would at a
> Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an
> Ulrich> attribute to DW_TAG_pointer_type (and then probably also
> Ulrich> DW_TAG_reference_type, DW_TAG_rvalue_reference_type,
> Ulrich> DW_TAG_ptr_to_member_type and possibly others).  Also, the
> Ulrich> implementation in GDB would need to be changed accordingly.
> 
> Ulrich> Any comments or suggestions on what to do here?
> 
> This kind of extension is pretty normal in DWARF, so I think it isn't a
> big deal to emit it.  Consumers are ordinarily expected to simply ignore
> things they don't understand.

Given Eric's GCC change above, this is no longer necessary now.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

Re: Issue with pointer types marked with scalar_storage_order

[Tom Tromey]

>>>>> "Ulrich" == Ulrich Weigand via Gcc <gcc@gcc.gnu.org> writes:

Ulrich> If we do want to byte-swap pointer types, then I guess we need
Ulrich> to still fix the debug info problem, which I guess would at a
Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an
Ulrich> attribute to DW_TAG_pointer_type (and then probably also
Ulrich> DW_TAG_reference_type, DW_TAG_rvalue_reference_type,
Ulrich> DW_TAG_ptr_to_member_type and possibly others).  Also, the
Ulrich> implementation in GDB would need to be changed accordingly.

Ulrich> Any comments or suggestions on what to do here?

This kind of extension is pretty normal in DWARF, so I think it isn't a
big deal to emit it.  Consumers are ordinarily expected to simply ignore
things they don't understand.

Tom