[PATCH] D127562: [lld-macho] Add support for exporting no symbols

Keith Smiley via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 13 09:54:33 PDT 2022


keith added inline comments.


================
Comment at: lld/MachO/Driver.cpp:1415-1416
     error("cannot use both -exported_symbol* and -unexported_symbol* options\n"
           ">>> ignoring unexports");
     config->unexportedSymbols.clear();
   }
----------------
int3 wrote:
> tangential & existing code, but this seems kind of redundant to me lol. We're already erroring out, doesn't seem like there's a need to tell the user we're ignoring `unexports`. (Not sure there's a need to clear the unexported symbols list either, but I suppose it might make any subsequent error messages less confusing.)
Removed this, it was silently ignored anyways because of the order of the if statement below. If we find a case where error messages are degraded without it I guess we should add it back with a test showing that case.


================
Comment at: lld/MachO/Driver.cpp:1561
 
-    if (!config->exportedSymbols.empty()) {
+    if (!config->exportedSymbols.empty() || exportNoSymbols) {
       parallelForEach(symtab->getSymbols(), [](Symbol *sym) {
----------------
oontvoo wrote:
> int3 wrote:
> > IMO this check is a bit confusing because it conflates a perf optimization with an actual difference in behavior. How about having the Config be something like
> > 
> > ```
> > struct Config {
> >   ...
> >   bool explicitExports = false;
> >   SymbolPatterns exportPatterns; // (can represent both `exportedSymbols` and `unexportedSymbols`)
> > };
> > ```
> > 
> > With `exportPatterns` interpreted differently based on the value of `explicitExports`. Then this `if` check becomes `if (config->explicitExports) { ...`
> > 
> > That said I know this is existing code, and refactoring it can be rightly said to be out of scope :)
> agreed - perhaps get rid of the two unexportedSymbols and exportedSymbols lists and have just one list then a flag to say what the list means?
> 
So I did the first suggestion here with the explicit exports, I'm not sure if it would be as clear if we joined exportedSymbols and unexportedSymbols but if folks generally prefer that I can change it!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127562/new/

https://reviews.llvm.org/D127562



More information about the llvm-commits mailing list