Re: duplicate dwarf2 reduction via comdat

[David B Anderson <davea at quasar dot engr dot sgi dot com>]

Jason writes:
>The symbols that a particular CU references need not be consistent, so
>long as they *refer* to the same thing.  For instance, my current
>implementation leaves the base types in the primary CU.  So if in one
>compilation, my CU for wa.h refers to the DIE for int using .LDIE0 and in
>another compilation uses .LDIE25, this does not matter; the CUs are still
>equivalent, and can be combined at link time.

Ron writes:
|Ah, the light finally dawns. The key point that finally clarified things
|for me is this: Suppose we start with interface file I.h that is included
|in two different modules A.c and B.h according to your proposal. Then we
|get
|
|    From compilation of A.c
|
|	DW_TAG_compile_unit for A
|
|	DW_TAG_compile_unit for I	// aka I#1
|
|    From compilation of B.c
|
|	DW_TAG_compile_unit for B
|
|	DW_TAG_compile_unit for I	// aka I#2
|
|
|Further, assume I#1 refers to something in A and I#2 refers to something
|in B. Finally the key point: after the linker has eliminated one of I#1 or
|I#2, the remaining I will still refer an entity within the same unit with
|which it was co-compiled. Whether you think of that reference in terms of
|symbols or offsets within sections does not matter--all that matters is
|that whatever I#1 referred to (which can occur anywhere in A) is semantically
|equivalent to whatever I#2 referred to (which can occur anywhere in B).

Ah. Yes, now I understand. Thanks for clarifying, Ron.

|Seems obvious now that it finally registers, but I think it leads to a not
|quite so obvious next question. Suppose there are two files I.h and
|J.h that are included in both A.c and B.c. So long as nothing in I refers to
|anything in J and vice versa, then what you describe works just fine. But
|what if something in J does refer to something in I?
|
|The concern is that there there is nothing about the underlying COMDAT 
|mechanism that assures that "consistent" choices will be made together.
|That is, that either I#1 and J#1 are chosen or I#2 and J#2 are choosen,
|but not (I#1 and J#2), nor (I#2 and J#1).

There is a rule that this violates.

The 'internal' references Jason mentions have to
be implemented as relocations with section offsets.
(ie, as unnamed offsets relative to a section , where the
section name is a global).  Right?

The Elf COMDAT (aka SECTION GROUP) rules forbid relocations
which are offsets into a COMDAT section.

The case Jason mentions, offsets into a non-COMDAT from
a COMDAT is of course just fine.

But Ron's elaboration covering headers with
references to each other seems to result  in  'internal'
relocations into a COMDAT and this is not something that can
really work and is not legal Elf COMDAT.

So this case cannot be supported using these 'internal'
references.

davea@sgi.com