[lto] I think we need a IL symbol table

[Rafael Espindola]

I have started looking at how to implement the linker plugin.

Things I have noticed so far from our design docs and current implementation:

*) GCC being monolithic and using a garbage collector will no be happy
to be loaded as a plugin. The plugin has to exec gcc in wpa mode.
*) The plugin must pass back a symbol table to the linker.
*) Currently the global decls are encoded in .gnu.lto_.decls. The
problem is that they are trees. The plugin cannot understand trees
without linking with gcc.

My idea to solve this problem is to have each lto1 invocation write
out a .gnu.lto_.symtab section. This would be a symbol *table* (more
of a summary) with all the information that the plugin needs in a
easier to understand format.

The format of the table would be just a sequence of the following structure:

Name. A null terminated string.
Def. A ld_plugin_symbol_kind (8 bits?)
Visibility: A ld_plugin_symbol_visibility (8 bits?)
Size: The symbol size (64 bits)
Comdat Key: A null terminated string.
Decl position: The offset in the file where the decl (the tree) can be found.

I am not sure if lto1 has the final position of the decl available
while writing out a entry into this symbol table. If it does not we
can use a uniq ID.

The variable sized strings make it impossible to seek in this table,
but it shouldn't be necessary. It is read only once. It is used to
construct the table that is passed to the linker and a corresponding
internal table with the position of each decl. When the plugin calls
wpa, it can uses only the decl position to identify the symbols. The
trees have all the relevant information and wpa reads them anyway.

Comments?

Cheers,
-- 
Rafael Avila de Espindola

Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland

Registered in Dublin, Ireland
Registration Number: 368047