> 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
