[Dwarf-Discuss] implementing SFN, support for multiple views per PC
it handling of view numbers in line number programs and their use by compilers? Is this (view numbers in line number tables, location list augmentation with view numbers referenced by a new attribute, the compact encoding of view numbers) something that DWARF might want to adopt in a future standard (presumably not version 5)? Are there any amendments that are deemed necessary right away? Thanks in advance, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] implementing SFN, support for multiple views per PC
On Sep 12, 2016, Cary Coutant wrote: > In the meantime, have you seen my proposal for two-level line tables > (a prototype of which is implemented in the google/gcc-4_9 branch)? >http://dwarfstd.org/ShowIssue.php?issue=140906.1 >http://wiki.dwarfstd.org/index.php?title=TwoLevelLineTables I hadn't. Thanks for the pointers. I reciprocate your interest :-) > At the bottom of the wiki page, I briefly mention a possible extension > to support checkpoint-based debugging, where location lists will need > to be able to refer to a logical location rather than a specific PC or > PC range. This may be relevant to your ideas -- I'm thinking your view > numbers might be similar to my logical locations. I'm still digesting the information in the proposal and trying to confirm they're roughly equivalent, or can be easily made so, but I have two related comments from a first reading of the links above: - the issue suggests referencing inlined functions by name. I'm not sure that's a very good idea, given templates, overloaded functions and whatnot. I think we'd be better off with a reference to the DW_TAG_inlined_function DIE instead. The DIE could then bring in such additional information as template parameters, function arguments and whatnot, and even identifying multiple inlined copies of the same function. - there seems to be a divergence between the issue and the wiki page WRT that very topic: where the former says "function_name" and suggests it refers to a string, the latter says "subprogram" and refers to an entry in the line number program header. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] implementing SFN, support for multiple views per PC
On Sep 13, 2016, Alexandre Oliva wrote: >> I'm thinking your view numbers might be similar to my logical >> locations. > I'm still digesting the information in the proposal and trying to > confirm they're roughly equivalent, or can be easily made so Considering they're limited to recommended breakpoints, I can confidently assert that they serve a significantly different purpose, and they would somewhat get in the way of the finer-grained view numbers. Consider, for example, that we want to represent in a location list that an operation that is NOT the recommended breakpoint for any (file,line,column) triplet modifies a register that used to hold the value of variable a, and that after the operation holds the value of variable b. With logical locations that represent only recommended breakpoints, location lists that were to refer to logical locations rather than PCs would not be able to represent that. Conversely, if location lists were to still refer to PCs rather than logical locations, we'd still be unable to represent in location lists the virtual advance from one line to another, since there isn't a different address to associate with the different location bindings. Another concern in my mind is the backward-compatibility of the new table. I'm very concerned about the disruption of the new split line number programs to existing debug information consumers; I'd much rather have something that extends existing information without breaking existing tools, enabling progressive adoption rather than flag days. But that's just me :-) I guess I'm also missing the motivation for all this disruption. I mean, I like the addition of context and subprogram, but I don't see why not add them as an extension to the exisiting line number program. I understand the argument about simplifying backtraces, but it seems to me that just having (back?)pointers from line number table to DIEs would accomplish a lot; I'm having a hard time believing that processing a somewhat smaller line number program even saves much in this case, since the odds that the points of the backtrace will coincide with the recommended breakpoints in the logical line table are pretty low. What am I missing something? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] implementing SFN, support for multiple views per PC
On Sep 9, 2016, Alexandre Oliva wrote: > SFN stands for Statement Frontier Notes, a technique I specified several > years ago and presented at the GCC Summit to allow for finer-grained > location information, so as to enable debug information consumers to > compute/observe multiple views of an underlying program's state at the > same program counter. More specifically, it would enable debuggers to > single-step over source code lines even though no actual instructions > were generated between the recommended breakpoints for those lines. > For some more details about the idea, please have a look at the paper > and the slides of the presentation at > http://people.redhat.com/aoliva/papers/sfn/ > TL;DR: each state in the source program's execution in the target > language's virtual machine amounts to a view of the program state. The > idea is to assign identifiers to (some) such views, and to add those > view identifiers to the line number table and to location lists. This > message is about how to do accomplish that in a compact and > backward-compatible way. Here is a proposal of extension to support location views that I would like to submit for inclusion in DWARF 6. View numbers A new column name "view" is added to the line number table. It gets its own register, computed as follows. After appending a row to the line number matrix, the view register is incremented. Every opcode that changes the address register (but not the op_index), except for DW_LNS_fixed_advance_pc, resets the view register to zero at the time the address register is changed. Rationale: we just need view numbers to be unique within the same address, as a fractional part. They might even be unique per op_index, but location lists represent addresses, so opcodes that advance only op_index will only reset the view when they advance the address, e.g. by exceeding maximum_operations_per_instruction in op_index. DW_LNS_fixed_advance_pc is available for compilers to use when an address changes is uncertain, e.g., when advancing past opcodes that may expand to an empty sequence, e.g. possibly-empty alignment sequences, optional no-operation opcodes or the like. View lists -- A DIE with a DW_AT_location list may also have a DW_AT_locviews attribute referencing a viewlist table. For each range in the location list (not its terminator), the viewlist should contain a corresponding pair of entries, one corresponding to the views that start and end the range. Each view is encoded as a separate uleb128 quantity. Each pair (address,view), formed by combining corresponding a beginning or end address from the location list with the corresponding view from the locviews view list, identifies the actual beginning or end of a view-augmented location list. Location lists that do not have a corresponding locviews list can be augmented by combining each one of its range addresses with a view number zero. A locviews list whose entries are all zero is equivalent to an omitted locviews list. How's this to get the discussion on this extension started? This is implemented in GCC, GIT branch aoliva/SFN. binutils+gdb branch users/aoliva/SFN has gas support for '.loc ... view' so as to generate more compact line number programs than GCC can on its own. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] implementing SFN, support for multiple views per PC
On Feb 23, 2017, Michael Eager wrote: > Please submit comments/proposals online at http://dwarfstd.org/Comment.php. > It greatly helps to specify the sections and pages that you propose > changing, as well as the text changed, added, or removed. Thanks, will do. I guess I will need some more discussion here, before having a concrete proposal, though, because of some changes prompted by changes in loclist in DWARF5. E.g., instead of what I had suggested, namely a separate attribute: >> A DIE with a DW_AT_location list may also have a DW_AT_locviews >> attribute referencing a viewlist table. and a separate list with matching entries for each loclist bounded location description entry: >> For each range in the location list (not its terminator), the viewlist >> should contain a corresponding pair of entries, one corresponding to the >> views that start and end the range. Each view is encoded as a separate >> uleb128 quantity. we could have: a. a new kind of location list entry that specifies a pair of view numbers, that must be placed e.g. right before a bounded location description entry, b. several new kinds of location list entries, each corresponding to an existing bounded location description entry kind augmented with a pair of view numbers Now, my intent has been to make this extension backward-compatible, so that debug info consumers unaware of view numbers can still use the location lists. I had hoped the newly-introduced entry kind identifiers could help accomplish this, but AFAICT it doesn't: a consumer wouldn't know how to skip an entry of an unknown kind, so adding any extended entry kind would make the location list unusable from that point on, and consumers might be well-justified to disregard the whole thing. Is that so? If loclists are really not supposed to be experimentally extensible, introducing a new experimental kind will be a bit of a challenge, even if it is proposed or even accepted for inclusion in future versions of the standard. With that, I'm leaning towards sticking with a separate attribute and viewlist form, as proposed before, in spite of the awkwardness of the matching list entries, instead of trying to fit the view numbers in extended loclist entries. Now, of course, if this becomes part of the standard, it might make more sense to encode the view numbers in the location list, even if it would make location lists of this new version of the standard incompatible with location lists of earlier versions. So, before I elaborate either form, I'd appreciate feedback on which would be the preferred way to introduce this sort of extension: introduce new loclist kind or kinds, in spite of breaking backward compatibility of lists, or use a new attribute and list form to hold view numbers? Thanks in advance, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] implementing SFN, support for multiple views per PC
On Mar 9, 2017, Alexandre Oliva wrote: > a. a new kind of location list entry that specifies a pair of view > numbers, that must be placed e.g. right before a bounded location > description entry, > b. several new kinds of location list entries, each corresponding to an > existing bounded location description entry kind augmented with a pair > of view numbers > Now, my intent has been to make this extension backward-compatible, so > that debug info consumers unaware of view numbers can still use the > location lists. > Is that so? If loclists are really not supposed to be experimentally > extensible, introducing a new experimental kind will be a bit of a > challenge, even if it is proposed or even accepted for inclusion in > future versions of the standard. > So, before I elaborate either form, I'd appreciate feedback on which > would be the preferred way to introduce this sort of extension: > introduce new loclist kind or kinds, in spite of breaking backward > compatibility of lists, or use a new attribute and list form to hold > view numbers? I got some private feedback suggesting I'd be better off proposing for DWARF6 an extension to loclists, rather than a separate attribute, and perhaps also some way to extend loclists in backward-compatible ways. The latter is easy (as described in a. or b. above), but I'm having trouble convincing myself that the latter can actually be done in a sensible way. We could have something in the CU that specified how to skip nonstandard loclist entry kinds potentially used in the CU's loclists. I envision a few possibilities: specify the expected length of an entry kind in the CU as a fixed quantity of bytes, or of leb128 values (interpretation of uleb or sleb is up to the reader), or have each entry start with a length. Supporting all of these possibilities wouldn't be too hard, and I can imagine uses for each of them, based on existing entry kinds and on the view range extension I'm designing. However, I can hardly imagine that a per-entry length would ever be used: it wouldn't be very compact; such an entry kind would probably not be standardized with an explicit length, so it would be forever a nonstandard extension; and an indirection layer could make an explicit length specification redundant (but then again it probably wouldn't end up being standardized that way). So, it would seem like we could make do with fixed-length extensions, but even those could be introduced through additional attributes, rather than as parts of loclists. But then it hit me: the indirection layer mentioned above could help us do away with even such fixed lengths: what if we had an entry kind that added, to the present loclist, entries from another loclist, starting at the entry whose address/offset is named, until its end-of-list entry (or an unsupported entry kind) is reached? We could then use this to factor out shared entries from loclists, and also for nonstandard extensions (a reader not acquainted with them would just take the unknown entry type as the end of the (sub?)list. So now this renders the notion of CU-specified fixed-length extensions redundant, and extensions can become standardized without encoding changes, they just cease to be potential loclist-terminating entries once they become part of the standard. Given this, does anyone see any reason to still propose fixed-length extensions "reserved" in the CU, as I described before? Conversely, does anyone think we'd better not support extensions to loclists whatsoever, not even through the "factoring" mechanism I described above, and resort to additional attributes to experiment with loclist extensions instead? Thanks in advance for any feedback on these matters, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] implementing SFN, support for multiple views per PC
--- In Section 2.6.2, page 43, add a bullet before "Default location description": * View description. This kind of entry must precede a Bounded location description, and it augments the starting and ending address of the Bounded location description with [view numbers|link to 6.2.5.0]. The addresses of a bounded location description that is not preceded by a view description are argumented with view number zero. In Section 2.6.2, page 45, add before 6++. DW_LLE_default_location: 6. DW_LLE_view_pair This is the only form of view description, and it has two unsigned LEB128 operands. The first and second values specify respectively the view numbers that augment the starting and ending addresses of the bounded location description the view description precedes. In Section 7.7.3, add to Table 7.10 the following entry: DW_LLE_view_pair | 0x09 == Extending loclists == This proposal introduces an extension mechanism to loclists, that can be used to share location list fragments among multiple location lists, and to experiment with extensions to location list standards in a way that does not break backward compatibility and that enables the experimental extensions to be welcomed into the standard without encoding changes. In Section 2.6.2: * List extension. This kind of entry extends a location list with entries from another loclist. It can be used to share list entries among multiple lists, and also to extend location lists with nonstandard entry kinds, in a way that will be disregarded by debug information consumers that do not support the extensions. In Section 2.6.2, page 44, add to 1. DW_LLE_end_of_list: Any non-standard entry kind may be interpreted as a DW_LLE_end_of_list entry. 2. DW_LLE_extend_loclistx This is a form of list extension, that has one unsigned LEB128 operand. The value is an index into the .debug_loclists section, like the operand of a DW_FORM_loclistx loclist. The contents of the location identified by the index are added to the base to determine the address of the first entry of a loclist whose entries are to be regarded as part of the loclist containing the list extension entry. In Section 2.6.2, page 45, add after 9. DW_LLE_start_length: 10. DW_LLE_extend_loclist This is a form of list extension, that has one offset operand. The value is an offset into the .debug_loclists section, like the operand of a DW_FORM_sec_offset loclist. The offset identifies the first entry of a loclist whose entries are to be regarded as part of the loclist containing the list extension entry. In Section 7.7.3, add to Table 7.10: DW_LLE_extend_loclist | 0x0A DW_LLE_extend_loclistx | 0x0B -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] implementing SFN, support for multiple views per PC
On Apr 27, 2017, Michael Eager wrote: > I don't know in what way the CAPTCHA "takes control of your computer", The CAPTCHA is software; running software means the computer is following the instructions encoded in the software, i.e., the software is controlling (the behavior of) the computer. > but I'll add your proposals manually. Thank you! -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
[Dwarf-Discuss] multiple entry points for inlined subroutines?
represented view numbers in most places where code addresses or address ranges could be used. Have these difficulties been run into before? Any advice to share? Thanks in advance, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] multiple entry points for inlined subroutines?
On Aug 11, 2017, Adrian Prantl wrote: > I'm unfamiliar with the term "view number". Is that a GCC-specific extension? For now :-) For an overview and links to further resources, including the proposal to bring it into DWARF6, see https://developers.redhat.com/blog/2017/07/11/statement-frontier-notes-and-location-views/ I'm going to speak about this at the upcoming GNU Tools Cauldron. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
[Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds
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 hackerhttps://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
Re: [Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds
ange_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 hackerhttps://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
Re: [Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds
On Jul 27, 2024, David Blaikie wrote: > If I'm following correctly, Alexandre - you're suggesting a situation where > an instance of a type, when it appears within a packed struct, may become > smaller than it would otherwise be? It's a philosophical question whether it's smaller in a packed struct or larger otherwise, a bit like whether the Tardis is bigger in the inside or smaller on the outside ;-D, but fact is that both kinds of uses of the same type can be common in a unit, so it would be desirable to represent those types with their sizes once, rather than e.g. override it at every variable or field. Right now, we represent two distinct, unrelated types to that end. ISTM that it would be better to be able to relate them, using one as the base type for the other. Sharing the bounds would be desirable, but it's not clear that omitting them in the derived type would achieve the desired result. That's what this thread is about. > (usually in C that's not the case - *nod*, the issue at hand came from Ada. > If you have a language where "packing" a member might cause it to become > smaller, not just cause the leading/trailing padding to be omitted - > perhaps that'd be better modelled, not with a new/distinct type, but with > the same mechanism as is used for bitfields in C? ie: using bit_size and > data_bit_offset? 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 -- Alexandre Oliva, happy hackerhttps://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
Re: [Dwarf-discuss] Proposal/clarification: "inherited" subrange bounds
On Jul 29, 2024, David Blaikie 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 hackerhttps://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
