> Can you elaborate on the DIE order constraint and why it was chosen? That > is, > > + /* The DIE with DW_AT_endianity is placed right after the naked DIE. > */ + if (reverse) > + { > + gcc_assert (type_die); > ... > > and > > + /* The DIE with DW_AT_endianity is placed right after the naked DIE. > */ + if (reverse_type) > + { > + dw_die_ref after_die > + = modified_type_die (type, cv_quals, false, context_die); > + gen_type_die (type, context_die, true); > + gcc_assert (after_die->die_sib > + && get_AT_unsigned (after_die->die_sib, > DW_AT_endianity)); + return after_die->die_sib; > > ?
That's preexisting though, see line 13730 where there is a small blurb. The crux of the matter is that there is no scalar *_TYPE node with a reverse SSO, so there is nothing to equate with for the DIE carrying DW_AT_endianity, unlike for type variants (the reverse SSO is on the enclosing aggregate type instead but this does not match the way DWARF describes it). Therefore, in order to avoid building a new DIE with DW_AT_endianity each time, the DIE with DW_AT_endianity is placed right after the naked DIE, so that the lookup done at line 13730 for reverse SSO is immediate. > Likewise the extra argument to the functions is odd - is that not available > on the tree type? No, for the reason described above, so the extra parameter is preexisting for base_type_die, modified_type_die and add_type_attribute. -- Eric Botcazou