[LLVMdev] lld deadstrip atoms

Nick Kledzik
Mon, 12 Nov 2012 22:26:09 -0000

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