comments on recent proposals

[Silverstein J.]

Here are some comments from SCO on the recent section indices
and COMDAT proposals from an object file/linking point of view.

Section indices:

We are okay with the suggested approach of using a parallel
section of symbol table indices, except that we would
prefer the names SHT_SYMTAB_SHNDX and .symtab_shndx to
SHT_SYMTAB_IDX and .symtab_idx.  Just seems to say more
clearly what they are for.

We are a bit uncomfortable with the notion of a variable
sized ELF header.  A different approach
to this problem was proposed to the Intel TIS group
(Tool Interface Standards) back in March of 1995.
In that approach, you indicated that there were lots of
sections by putting a 1 in the e_shnum field of the ELF
header.   The first section header entry in an ELF file
always contains all zeros.  If the e_shnum field is 1,
then the sh_size field of the first entry would contain
the real number of sections.  Although this is not in
the TIS proposal, we could pick another field, say
sh_addralign, to contain the index of the section
header string table section.  This approach requires 
reading the section header table in 2 pieces for programs 
with more than the maxinum number of section header table entries,
but it keeps the ELF header a fixed size.

COMDAT:

We have 3 main concerns here.  First, the use of
a symbol table entry for the name of the COMDAT group
section and the requirement that if the same symbol is
defined in a non-COMDAT section, then all COMDAT groups
of that name are tossed.  This would cause, at least for our
linker, great complications in processing.  It would
mean you would need to read all the object files,
processing their symbol tables and saving COMDAT sections
on a list for later use.  Then you would need
to go back and decide which COMDAT groups to keep
and which to toss, undoing some of the things you
did to the symbol table in the process.  It may
also be difficult to keep sections in input order
with this approach.  In the HP approach, where the
name of the COMDAT group section was what you used for
comparison and you simply kept the first group with a 
given name, you could make decisions on which sections
and which symbols to toss as you were reading the input
files, making implementing COMDAT very simple for the linker.

We are also concerned with the assumption that seems to
be built into this approach (and HP's) that a relocatable
file can contain multiple sections with the same name
and attributes.  This may be simple to accomplish in
a compiler that goes right to object code, but it is more
difficult when you are generating assembly code: how
does an assembly file distinguish between the 10 sections
in this object named .text?  I guess there are ways, but
they seem awkward.  We would rather an approach where
COMDAT sections would be uniquely named within a relocatable,
and the individual sections had some way of specifying which
output section they should be merged with.  The Watcom
COMDAT proposal to TIS used the sh_link field of a COMDAT
section for this purpose.  If .foobar is an SHF_COMDAT section
and its sh_link field points to .text, then you merge .foobar
into the .text section on output.

Finally, we have real concerns about how DWARF2 interacts with
COMDAT.  We haven't worked our way through all the issues,
but at least 2 things stand out.  We assume the intention is 
that each COMDAT group would contain its own .debug_info 
and .debug_line sections?  It seems as if these sections
have to be either compilation unit entries in their own
rights, or pieces of compilation unit entries that can
be pasted together by the linker.  In the first case,
it seems that you would have to duplicate all of the DWARF
type information for the dot-o in each of the COMDAT
debug_info sections, since the type information is put
together with references that are relative to the beginning
of their containing compilation unit entry.  In the second
case you have the problem of the compilation unit header.
This header contains the length of the debugging information
entries for the entire compilation unit.  It is not clear
to us how to generate this length when you are pasting
together individual pieces of a single compilation unit record.

Has anyone had any experience in working through the interactions
of COMDAT with DWARF2?
-- 
Joel Silverstein and Dave Prosser
SCO Development Systems
jds at sco.com and dfp at sco.com