[Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds

[Ron Brender]

>Consider a type that is a subrange of an integral base type, with an
>explicitly specified bit size smaller than the bit width of a storage
>unit.
>
>When used for a standalone variable, its byte size is the same as that
>of the base type, i.e., the type is padded to a whole unit.

The variable's size has to be at least that of the base type. But it could
be
larger. Especially likely if it is in a register. Actually it could be
smaller if the
compiler can prove the possible range of actual values is smaller than
allowed by the base type.

>However, when used for a packed record type, however, it takes on the
>requested bit size, without any padding whatsoever.

That is the purpose and meaning of packed, yes.

>Because of the different sizes, this requires two distinct types to be
>defined in debug info.

There is no basis for this claim AFAIK.

>Despite sharing the same bounds, however, it seems that the bounds have
>to be explicitly mentioned in both types.

Equally unfounded. The type char in C has a range of -128..127 even if
no bounds are explicitly given.

>That's because, AFAICT, when DW_AT_lower_bound is omitted in a
>DW_TAG_subrange_type, it is implied as either 0 or 1, depending on the
>source language, while DW_AT_upper bound is unknown.

Yes.

>There doesn't seem to be any provision for the bounds to be inherited
>from the base type.

The bounds of the subrange type do have to be within the bounds
of the basis type  (even if unknown).

>So now we have to resort to something like:

>  (x) DW_TAG_base_type
 >   DW_AT_byte_size 1
 >  [...]
 >(y) DW_TAG_subrange_type
 > DW_AT_name ...
 >  DW_AT_type x
 >  DW_AT_lower_bound L
 >  DW_AT_upper_bound U
 >  [...]
 > (z) DW_TAG_subrange_type
 >   DW_AT_type x (could it be y?)
 >   DW_AT_bit_size N
 >   DW_AT_lower_bound L
 >   DW_AT_lower_bound U

Not so as stated above.

>but if we had the possibility of inheriting bounds from the base type,
>it could be:

>  (x) DW_TAG_base_type
>    DW_AT_byte_size 1
>    [...]
>  (y) DW_TAG_subrange_type
>    DW_AT_name ...
>    DW_AT_type x
>    DW_AT_lower_bound L
>    DW_AT_upper_bound U
>    [...]
>  (z) DW_TAG_subrange_type
>    DW_AT_type y
>    DW_AT_bit_size N
>    [bounds are inherited from y]

Subrange y seems unnecessary which will result in the range -4..3. If you
want some other range then you can add DW_AT_lower_bound/upper bound (that
specifies a range with at most 2**N possible values).

>I realize that this could bring complications in case the inheritance is
>not immediate.  Say, the base type could be a DW_TAG_const_type variant
>of a subrange type.  So, if we were to allow this sort of inheritance of
>bounds, it should probably also cover multiple levels.


>A simpler alternative could be to have another tag, say
>DW_TAG_[un]padded_type, for a different-sized variant of a type.  As
>usual for such tags, other properties would be inherited, including the
>bounds.

Because two base types are not needed in the first place, no additional tag
is needed.

On Fri, Jun 14, 2024 at 3:00 AM Alexandre Oliva via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

>
> Consider a type that is a subrange of an integral base type, with an
> explicitly specified bit size smaller than the bit width of a storage
> unit.
>
> When used for a standalone variable, its byte size is the same as that
> of the base type, i.e., the type is padded to a whole unit.
>
> However, when used for a packed record type, however, it takes on the
> requested bit size, without any padding whatsoever.
>
> Because of the different sizes, this requires two distinct types to be
> defined in debug info.
>
> Despite sharing the same bounds, however, it seems that the bounds have
> to be explicitly mentioned in both types.
>
> That's because, AFAICT, when DW_AT_lower_bound is omitted in a
> DW_TAG_subrange_type, it is implied as either 0 or 1, depending on the
> source language, while DW_AT_upper bound is unknown.
>
> There doesn't seem to be any provision for the bounds to be inherited
> from the base type.
>
> So now we have to resort to something like:
>
>   (x) DW_TAG_base_type
>     DW_AT_byte_size 1
>     [...]
>   (y) DW_TAG_subrange_type
>     DW_AT_name ...
>     DW_AT_type x
>     DW_AT_lower_bound L
>     DW_AT_upper_bound U
>     [...]
>   (z) DW_TAG_subrange_type
>     DW_AT_type x (could it be y?)
>     DW_AT_bit_size N
>     DW_AT_lower_bound L
>     DW_AT_lower_bound U
>
> but if we had the possibility of inheriting bounds from the base type,
> it could be:
>
>   (x) DW_TAG_base_type
>     DW_AT_byte_size 1
>     [...]
>   (y) DW_TAG_subrange_type
>     DW_AT_name ...
>     DW_AT_type x
>     DW_AT_lower_bound L
>     DW_AT_upper_bound U
>     [...]
>   (z) DW_TAG_subrange_type
>     DW_AT_type y
>     DW_AT_bit_size N
>     [bounds are inherited from y]
>
> I realize that this could bring complications in case the inheritance is
> not immediate.  Say, the base type could be a DW_TAG_const_type variant
> of a subrange type.  So, if we were to allow this sort of inheritance of
> bounds, it should probably also cover multiple levels.
>
>
> A simpler alternative could be to have another tag, say
> DW_TAG_[un]padded_type, for a different-sized variant of a type.  As
> usual for such tags, other properties would be inherited, including the
> bounds.
>
> This feels like a waste of a tag, though; DW_TAG_subrange_type seems
> like it could be enough.
>
> --
> Alexandre Oliva, happy hacker
> https://FSFLA.org/blogs/lxo/
>    Free Software Activist                           GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but
> very few check the facts.  Think Assange & Stallman.  The empires strike
> back
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240615/3ea74861/attachment.htm>