Also strip Swift symbols when --objc_enable_binary_stripping is passed

[thii]

Resolves #13122

[keith]

kinda surprised -x wasn't here before

[cpsauer]

Hmm, you guys sure -x belongs in the stripping of executables?

My impression was that one only wanted -x for dynamically loaded libraries (dylibs/kexts/loadable bundles) to preserve the global symbols needed to export an ABI from. From the strip man page, I'd guess you might want ("-u", "-r" instead for executables--and that that'd strip all the unneeded symbols?

Would you want to also strip Swift symbols in dynamically loaded libraries? (switch case immediately above) Apologies if I'm missing something--it's not clear to me what makes swift symbols special during the stripping process. Just ran across this while adding the -x case to fix loadable bundles in #13314

[jin]

cc @trybka

[allevato]

I'll defer to @trybka on this one. We've discussed in the past that this flag is fundamentally broken because it conflates two meanings of "strip" (symbols and dead code stripping) and has other side effects on top of that; I'm not sure if adding more behavior to this already broken flag is the right thing to do or if it would have other undesirable side effects.

[DavidGoldman]

Would it make sense to file a radar/feedback for what API we would need from strip?

[allevato]

Would it make sense to file a radar/feedback for what API we would need from strip?

Not sure I follow. When I say "this flag" I'm referring to --objc_enable_binary_stripping—I don't see anything here that needs Apple's attention. The problem is the single flag in Bazel that combines too many unrelated behaviors, and this PR would add more behavior to that.

[trybka]

+cc @jyknight

[trybka]

--objc_enable_binary_stripping is a confusing flag that conflates at least two meanings of "strip" and also has other side effects. Dead code elimination happens at link time, and a debugging symbol strip action is registered for final executable links.

We'd like to eliminate it altogether, but there are some... complications.
I'm going to look into externalizing an internal doc I have on the matter to provide additional context.
As such, I'm hesitant to add more meaning to it (i.e. having it affect Swift, too).

It's not clear what exactly to do here--but I think that the hard-coded action created by the ObjC rules should go away.

-x might be fine, but in practice doesn't remove most symbols, because they are all defaulted to dynamically exported.

[keith]

If this isn't the right path I wonder if we should make --stripopt or something apply to this strip logic too so folks can do something to solve this

[trybka]

https://github.com/trybka/scraps/blob/master/Apple_Stripping.md

[trybka]

I think it would be sensible to make this register a strip action like cc_binary does, and then the options can be configured in the Crosstool.

[steeve]

Jumping on this, emergetools.com actually recommends -rSTx -no_code_signature_warning for all binaries.

[keith]

Please checkout #14951

[keertk]

Hi @googlewalt, was doing some checks of unmerged PRs and wanted to see if this one is still needed and good to be approved/merged internally?

[thii]

Closing in favor of a more proper solution at #14951.