[LLVMdev] lld deadstrip atoms

[Nick Kledzik]

On Nov 9, 2012, at 10:31 AM, Shankar Easwaran wrote:
> Hi Nick,
> 
> Dead stripping optimization needs a way to setup the roots which are live. The current code in Resolver does it by
> 
> 1) setting all the global defined atoms to be the live set when building shared libraries (_options.allGlobalsAreDeadStripRoots)
> 2)  Or, uses a list of names that are dead strip roots (other types)
> 
> Question:-
> ***********
> How are the dead strip root names supposed to be set ? Does each Reader need to set specific information on what are the dead strip roots ?
On darwin there are two mechanisms: 1) individual symbols can be marked never-dead-strip.  This is set on Objective-C meta data (e.g. ObjC class data structures) because ObjC is a dynamic language where the only use of a class might be not know until runtime.  2) The linker may be passed a list of symbols to export (-exported_symbols_list).  Those symbols are the dead strip roots.  Typically usage is that a dylib has a fixed "interface" (API).  Only those symbols are exported from the dylib.  All others are marked hidden.  And if the -dead_strip linker option is used, any atoms not reachable from the API atoms are dead stripped away.


> 
> There is a flag in the DefinedAtom to determine whether to deadstrip an atom,
> 
> deadStripNormal, deadStripAlways, deadStripNever
> 
> Question :-
> ************
> a) What is the difference between deadStripNormal/deadStripAlways ?
The idea for deadStripAlways is that some file formats have atoms which are optional and should only be kept by the linker if actually used by something.  I do not plan to use it for mach-o.

> 
> b) Further looking, there is a compiler attribute __attribute(used)__ which could be set for each symbol, but this is only a compiler hint. The information is not passed in the symbol table. If this is not passed in the symbol table to the linker, why is it in the DefinedAtom ?
In mach-o it *is* passed on to the linker by the compiler.  It is the N_NO_DEAD_STRIP bit in the n_desc field of the nlist struct.  Are you saying that that information is not recorded in ELF .o files?


-Nick