<div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In Pascal (free pascal) the string type (some of them) have an internal <br>
field (not accessible to user code) that stores the encoding.<br>
<br>
That can be an ASCII-page, or utf8, or raw (just bytes as they are)....<br>
<br>
For a debugger this info is useful to display the string correctly. A <br>
debugger would want to convert the string to the encoding used by the <br>
terminal before printing it).<br>
<br>
I am looking for ways how that could be encoded in DWARF?<br>
<br>
The first step would be e.g. some attributes to describe the location <br>
and size of that field.<br></blockquote><div><br></div><div>For this, I'd look to the DW_AT_string_length, DW_AT_string_length_byte_size/_bit_size attributes as a model. You could add DW_AT_string_encoding which would take a location expression (with an implicit push object address) that yields the location of the encoding field, and DW_AT_string_encoding_{byte|bit}_size attributes that give the size of that field in your internal string representation.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The 2nd part would be a mapping of the values in that field.<br>
<br>
That 2nd part may not need to be part of the encoded DWARF description.<br>
It could be just per language defaults (a debugger would have to know <br>
the values that each compiler may use).<br>
I.e. I am not sure, but this may be compiler rather than language dependent.<br>
<br>
Optional, compliers could add a global list of mapping to pre-defined <br>
DWARF constants.<br>
That would be some form of list with pairs of<br>
- "compiler encoding value"<br>
- DWARF constant<br>
<br>
<br>
This may affect the encoding used in the base type for the char.<br></blockquote><div><br></div><div>If different compilers use different constants, you'd have a compatibility problem. On the other hand, if this is a language extension, then maybe you don't expect it to be interoperable across different compilers (and indeed the internal structures of the string type may differ as well).</div><div><br></div><div>I'd be tempted to leave this as a job for the debugger, but if you wanted to try to map the compiler's encoding values onto DWARF encoding constants (DW_ATE_*), you could have a DW_TAG_string_encoding_map DIE in the compilation unit. This could either take a single attribute with a block-form value containing your list of pairs, or it could have multiple children, each with two attributes that give the compiler's encoding value and the equivalent DW_ATE_ constant, respectively.</div><div><br></div><div>The DW_TAG_string_type DIE has a DW_AT_type attribute that gives the type and encoding of the characters in the string. For strings where the encoding is dynamic, you might also want to invent a new DW_ATE_dynamic or DW_ATE_none encoding value, or use DW_ATE_unsigned_char, or just omit the DW_AT_type altogether.</div><div><br></div><div>If this is a compiler extension, I'd suggest you use DWARF extensions for this information. If it's part of the language standard, feel free to follow up with a proposal along these lines.</div><div><br></div><div>-cary</div><div><br></div></div></div>