[gold] "patch" for the incremental link design document

[Rafael Espindola <espindola at google dot com>]

I have added the incremental design document to

http://gcc.gnu.org/wiki/GoldIncrementalLinking

One thing that is missing in it is that we need the symbols present in
archives so that we can handle the following case:

gcc a.o b.a  -o c

Changing a.o can cause us to pull a new file from b.a. We will do a
full relink is this case, but we should be able to detect the need to
do so by looking only at the files that changed and at the incremental
information.

Some options I discussed with Ian a bit

*) In the "For an archive" part of the design add
3. 4 byte count of global symbols
4. For each symbol:
   1. 4 byte offset of the symbol name in .gnu_incremental_strtab
   2. 4 byte padding

This is just enough information for us to force a relink when necessary.

*) Another option is to change the "For an object file or shared
library" section into:

For an object file, shared library or archive

1. 4 byte count of input sections

    * Always zero for a shared library or archive.

2. 4 byte count of global symbols (including the ones from unused objecs
   in an archive)

3. For each input section:

   1. 4 byte offset to section name in .gnu_incremental_strtab section
   2. 4 byte output section index
          * If input section is omitted, this is zero.
   3. 8 byte offset of input section in output section
   4. 8 byte input section size

4. For each global symbol:

   1. 4 byte index into output global symbol table (- if from an
unused archive member)
   2. 4 byte offset to next linked list entry
          * Linked list starts from global symbol list.
          * Offset is to entry in input file list.
   3. 4 byte count of relocations for this file.
   4. 4 byte offset to relocations in .gnu_incremental_relocs section.

The main difference of both proposals is when walking the command line
to find if a symbol was already defined or to find if a new archive
member is needed.

With the second proposal archives will show up in the regular linked lists.

With the first proposal we would have to
*) Be conservative and relink if any archive header changed
or
*) "patch" the archives in the linked lists at runtime

An advantaged of the first proposal is that all the archive specific
information is kept in the same place.

Thoughts, preferences?

Cheers,
-- 
Rafael Ãvila de EspÃndola