Re: linkonce and dwarf 2

[Ian Lance Taylor <ian at zembu dot com>]

   From: Jason Merrill <jason@cygnus.com>
   Date: 16 Nov 1999 18:00:37 -0800

    >       .debug_info : { *(.debug_info* .gnu.linkonce.d.*) }

    >    then the section contents will retain the above order in the output,
    >    rather than lumping all the _head bits together and so on.

    > I think this will cause the GNU linker to output all the .debug_info*
    > sections followed by all the .gnu.linkonce.d.* sections.  I may be
    > mistaken, though.

   I figured that if that's what you wanted, you would write

     *(.debug_info*)
     *(.gnu.linkonce.d.*)

I don't think there is actually any difference between the two.
Again, I may be mistaken.  I haven't actually tried it.

I don't see anything in the documentation which promises anything
either way.

    >    The problem with this scheme is that the CU header specifies the
    >    length of the CU, and there would be no way to compute this at
    >    compile or assembly time; it would depend on which subsections had
    >    been kept or thrown away.  Is there currently any way to express
    >    link-time arithmetic in gas?

    > Only via relocations.

   I suppose what I was asking was "is there a relocation which could express
   the difference between two arbitrary symbols, and is there gas syntax which
   could generate it?"

There is no such relocation for most object file formats.  In some
cases, you can simulate it by using a PC relative relocation with a
complex addend.

    >    3) Another scheme would be to do something like the stabs BINCL
    >    optimization, and put all the info for a header into its own CU.
    >    This would also be useful for C, while the two schemes above would
    >    mainly work for C++ (because of the stronger rules for type names in
    >    C++).  The problem with this scheme is that it would require linkonce
    >    and symbol resolution semantics like those of the BINCL optimization;
    >    we would only want to discard duplicates if they were identical, and
    >    we would want references to be bound to the appropriate instance if
    >    not all are discarded.

    > I'm not sure why this is a serious problem.

   Hmm?  Because headers might have different contents in different objects,
   whether because of macros, template instantiations or whatever.  If I have
   a DIE referring to a symbol defined in a comdat that is discarded and that
   symbol isn't defined elsewhere, I lose.

The BINCL optimization only discards duplicate headers which are the
same.  It hashes the information; if headers have different contents,
both instances are kept.

Ian