[Dwarf-Discuss] Fission + cross-CU references (ref_addr)

[David Blaikie]

On Fri, May 5, 2017 at 11:14 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

> I was mentioning this mostly by way of opportunistically suggesting "it
> might be a thing that would be good to think explicitly about, possibly
> allow, and design this new stuff around the possibility, perhaps".
>
> The entire point of a type unit is to allow size reduction by
> deduplication.  Any kind of section-offset reference into a TU depends on
> that exact instance of the TU to remain; therefore such references defeat
> the purpose of type units.  Do we need to have explicit words that say so?
> I hope not.
>

Sure, agreed for a TU to TU reference.


> Similarly, a reference from a TU to a CU implies that the TU is not
> self-contained and therefore the exactness of any duplicates is suspect.
>

I disagree here. TU can be semantically equivalent while not being
bit-for-bit identical, and the presence of a TU->CU reference doesn't make
it less reliably able to maintain that property.


>   What guarantees that the information referred to is the same across all
> "duplicate" TUs or otherwise does not affect the semantic content of the TU?
>

The same guarantees that exist without TU->CU references, I would think?
It's up to the implementation to ensure that any two TUs are semantically
equivalent. (so in one TU you might have a TU->CU reference to refer to a
type, in another you might have a declaration of that type in the TU
itself, because no definition is available)


>   There is none.  So, this kind of reference defeats the purpose of a TU.
> Do we need to have explicit words that say so?  I hope not.
>
>
>
> Adding semantics to "contributions" in the .dwo file seems like a big step
> that wasn't present before I think.
>
> It would mandate the use of (at least 2) sections when using Fission+type
> units, reducing some compression opportunity
>
>
>
> Deduplication by COMDAT in v4 was depending on semantics of object-file
> characteristics;
>

But that's an implementation detail - not a requirement of the format to
convey the necessary information. The necessary grouping of chunks of DWARF
seems to be a semantic feature that hasn't been necessary to interpret
DWARF correctly until this point/proposal. An inefficient but correct
implementation could concatenate all the DWARF together, including the
duplicates - or could do the DWARF aware thing that DWP requires and look
for type unit boundaries and deduplicate on those, etc.

eg: if a file format didn't support separate chunks of sections by the same
name (which, to me, seems like a somewhat odd feature, TBH - caught me by
surprise that "you don't need to use COMDATs for type units in DWO files"
meant anything other than "all the type units go in the (singular)
debug_types section") it wouldn't support this format without extra
bookkeeping which would seem weird to me. In all prior cases the DWARF
bytes have described the bounds of relevant chunks that a consumer would
need to care about, right? (pretty much everything has a header that
specifies its length, and/or has terminators to specify where it ends and
the next thing begins, etc)

Type units enabled the chunks to be separated so existing linker features
could handle them - but didn't /require/ them to be separated to convey
specific DWARF semantics. That's the distinction I think I'm trying to
draw/be surprised by/etc.

DWARF requires a format that supports different named sections - but until
this proposal/discussion hasn't required it to support the notion of
different chunks in the same named section, it seems?

Sorry, just trying different phrasing to see if I can get something that
seems to best convey what's in my head - not sure if it's making sense.


> additional semantics don't seem like that big a leap to me.  LTO
> implications (e.g. cross-CU references in a DWO file, which can't have
> relocations) are a new thing that we hadn't considered before.  I don't
> have a problem with new situations with new implications needing new
> paragraphs/sections/requirements/whatever.  We even have a place to put
> stuff like that now (Appendix E).
>
> --paulr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20170505/96077e09/attachment-0001.htm>