[lld] adding deadStrip() to undefined Atoms

Hi,

Can we add deadStrip() to undefinedAtoms as well ?

This will enable to choose whether we want to set the property deadStripNormal or deadStripNever on them.

Also I think it will be cleaner for atoms to be added to deadStripRoot set using a single API.

Thanks

Shankar Easwaran

I think that’s a good idea. One thing we should be careful is not to unconditionally propagate dead strip attribute from undefined atom to defined one, but choose the most restrictive one (deadStripNever takes precedence over deadStripNormal) when replacing an undefined atom with an defined one.

Can you give more more background on this? When would you want and undef that causes the whatever defined atom replaces it to be never dead stripped?

For darwin's current linker (ld64), the driver adds an initial undefs to the dead strip root set.

-Nick

We have these options a) -entry b) -init c) -fini The atoms created for this shouldnot be dead stripped, as there is an explicit reference from the command line. The other options such as a) --defsym newsymbol = oldsymbol + 100 b) --wrap newsymbol have the other effect that if there is no reference to the symbols the atoms are removed. Also rather than having the symbols seperately considered in the Driver, on whether we want to add to the deadStripRoot set or not, we can just use the attributes on the atom to place them in the deadStripRoot set / not. On the similiar lines, I think it should become an atom property itself (having absoluteAtoms also have this property set) ? What do you think ? Thanks Shankar Easwaran

We have these optionsa) -entry b) -init c) -fini The atoms created for this shouldnot be dead stripped, as there is an explicit reference from the command line.

Those should be added to LinkingContext’s initialUndefinedSymbols. Then we should change Resolver::deadStripOptimize() to add all initial undefines (along with deadStripRoots) to the dead strip roots. InitialUndefines are atom names that need to have an implementation, that means they should not be dead stripped. With that change in place, this half of your issue is solved.

The other options such as

a) --defsym newsymbol = oldsymbol + 100
b) --wrap newsymbol

have the other effect that if there is no reference to the symbols newsymbol, and __wrap_newsymbol, the atoms are removed.

Off hand, I’m not sure how to support —wrap in general. I can see having the command line object create an alias atom (scope=linkageunit) which is named newsymbol and references __wrap_newsymbol. But I don’t know how to model uses of __real_newsymbol. But there is nothing to dead strip here. Alias are zero size and making it scopeLinkageUnit means it won’t escape. So, I don’t see anything deadStrip wise that needs to handling here.

Also rather than having the symbols seperately considered in the Driver, on whether we want to add to the deadStripRoot set or not, we can just use the attributes on the atom to place
them in the deadStripRoot set / not.

On the similiar lines, I think it should become an atom property itself (having absoluteAtoms also have this property set) ?

Like aliases, AbsoluteAtoms have no size, so I don’t see what dead stripping them would gain.

-Nick