>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 >
-- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
