Alexandre, Since you mention that this for Ada, I'll mention this:
In our old Ada implementation, we make a decision not to use DW_TAG_subrange_type as a general-purpose solution for Ada; we used it only for array bounds, as described when it's introduced in section 5.5 Array Type Entries. (Well, we were using the DWARF 2 spec, but you get the idea.) For Ada derived types & subtypes, we created something new: DW_TAG_derived_type and DW_TAG_subtype. We had several reasons for doing this. But one benefit was that, for packed types, we used anonymous DW_TAG_subtype DIE's instead of DW_TAG_subrange_type DIE's. They had DW_AT_subtype_parent attributes referencing back to the types on which they were based, and we had the freedom to say that they inherited all aspects from the their "subtype parent", unless overridden. Overridings included size, encoding, and each of the bounds, individually. A DW_TAG_subtype could be reused for all packings of a particular type, if the compiler was sure they all were identical. But, of course, it's possible to "quasi-pack" types using representation clauses, so it's entirely possible to need more than 2 different representations. FWIW, we didn't use DW_TAG_subtype for subtypes *initially*. It was only after attempting to use DW_TAG_subrange_type for a while, and finding it unsuitable that we created the new tag. And it was cleaner to have a new tag that none of the DW_TAG_subrange_type array-specific baggage. Todd On 7/30/24 19:21, Alexandre Oliva via Dwarf-discuss wrote: > CAUTION! External Email. Do not click links or open attachments unless you > recognize the sender and are sure the content is safe. > If you think this is a phishing email, please report it by using the "Phish > Alert Report" button in Outlook. > > On Jul 29, 2024, David Blaikie <dblai...@gmail.com> wrote: > >>> The situation is not very different, but in Ada one can specify the >>> target size (in bits) for the type (which may require biased >>> representations, but that's besides the point). Despite the specified >>> size, standalone variables and members of unpacked types use full >>> storage units, unless packing is requested. See >>> e.g. >>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/gnat.dg/bias1.adb >> I see, so do I understand correctly that you'd prefer not to use the >> bitfield style representation, because it'd be repetitious? > There's that (Dwarf aims for compactness), but there's also the fact > that the type size is explicitly specified as the smaller bit size, so a > proper representation of that type would carry that piece of > information. ISTM that ideally the larger, full-unit-sized variant > would be the one using explicit sizes or a separate type variant > inheriting the same bounds. > > But the problem I see, and try to raise in this thread, is that there's > no way for a subrange type to inherit bounds from another subrange type, > which once again plays against compactness. > > -- > 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
