lld deadstrip atoms

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:-

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

Hi Nick,

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?

On ELF x86_64, I dont see the information being passed. Is clang planning to add this support ?

Thanks

Shankar Easwaran

I don't know what ELF supports. For mach-o, the information is passed via the .no_dead_strip directive:

[/tmp]> cat foo.c
__attribute__((used))
void foo() {}

[/tmp]> clang -Os -S foo.c

[/tmp]> grep foo foo.s
  .globl _foo
_foo: ## @foo
  .no_dead_strip _foo
[/tmp]>