[Dwarf-discuss] Idea/Question: Add DW_AT_LowerBound to DW_TAG_String

[Cary Coutant]

>
> In Pascal the index normally is 1 based.
> But compilers like FPC and Delphi support a directive "{$ZEROBASEDSTRINGS}"
> https://gitlab.com/freepascal.org/fpc/documentation/-/work_items/39484
> which changes this to 0 based.


> It might be desire-able to add this to DWARF.


You mean DW_TAG_string_type, right?

This seems like a reasonable extension. We've always claimed DWARF is
"descriptive, not prescriptive", meaning that if a tag or attribute makes
sense in a context we don't cover in the document, it's still generally OK.
In this case, the presence of a DW_AT_lower_bound attribute in a
DW_TAG_string_type would have an obvious meaning, and a consumer that
ignores it is no worse off than if the producer omitted it.

It may not be quite as obvious as it sounds, though: DW_AT_lower_bound is
currently defined only for subrange types (DW_TAG_generic_subrange and
DW_TAG_subrange_type), which are used to define the bounds of each
dimension of an array. Since strings are inherently one-dimensional, the
use of one or more subrange tags as children of DW_TAG_string_type seems
unnecessary (unless anyone is thinking of proposing multi-dimensional
strings!).

Given a known use case for DW_AT_lower_bound as an attribute of
DW_TAG_string_type, I'd support a proposal to add it to DWARF V6. My
opinion is that you should feel free to use it anyway in current versions
of DWARF, as long as you have an agreement with any relevant debuggers.

What about DW_AT_upper_bound? For string types, we have
DW_AT_string_length, et al., but providing lower and upper bounds would be
an alternate way to represent the string length. The argument for this is
not as strong: if you replace DW_AT_string_length with DW_AT_upper_bound,
you risk breaking some consumers.

If you like, I'll file this as a new proposal (without upper bound).

Also Pascal strings (some of them) are ref-counted and have other fields
> (like encoding).


> Ref-count may be something generic (also applies to some arrays). And
> may therefore deserve an attribute of its own?


With respect to ref counts, I'd like to see a more fleshed-out proposal
with some background about how it could be useful to a consumer.

-cary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20260420/25205cd5/attachment.htm>