This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho] Handle error cases properly for -exported_symbol(s_list)
ClosedPublic

Authored by gkm on Mar 10 2021, 6:32 PM.

Details

Summary

This fixes defects in D98223 [lld-macho] implement options -(un)exported_symbol(s_list):

  • disallow export of hidden symbols
  • verify that whitelisted literal names are defined in the symbol table
  • reflect export-status overrides in nlist attribute of N_EXT or N_PEXT

Thanks to @thakis for raising these issues

Diff Detail

Event Timeline

gkm created this revision.Mar 10 2021, 6:32 PM
Herald added a project: Restricted Project. · View Herald Transcript
gkm requested review of this revision.Mar 10 2021, 6:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 10 2021, 6:32 PM
gkm updated this revision to Diff 329821.Mar 10 2021, 6:51 PM
  • add missing test for erroneous export of private symbol

Thanks!

lld/MachO/SyntheticSections.cpp
588

Should we error in this acccessor style function? Won't we get two errors if we call this for relocs and for symbol table?

nit: If you end strings after \n, clang-format formats them nicer: replace "\n>>> defined in" with "\n" ">>> defined in"

I'd find the diff easier to read if it just extracted the existing conditional out of the loop for now. Maybe this diag could move to a follow-on patch?

612

Could we do this like -u handling in by adding Undefineds in the driver code instead of having a special case here? Then we wouldn't have to make the SymbolTable interface more complicated for this feature.

lld/test/MachO/export-options.s
54

https://en.wikipedia.org/wiki/Blacklist_(computing)#Controversy_over_use_of_the_term

Probably good to just use the actual flag names here (exported symbol list, unexported symbol list)

79

Should this have a -NOT for _hide_globl?

gkm marked 4 inline comments as done.Mar 12 2021, 12:36 AM
gkm added inline comments.
lld/MachO/SyntheticSections.cpp
588
  • You are correct that an accessor should not error. In my limited testing, I don't see the message twice because the first error precludes writing the output where the second error might happen.
  • With the proposed change, clang-format turns two lines onto four, which isn't so nice after all:
error("cannot export hidden symbol " + symbolName +
      "\n"
      ">>> defined in " +
      toString(defined->getFile()));
612

I moved the check for undefined exported symbols the the same place where we check undefined -u options. It didn't make sense to lump exported symbols in with explicit undefined symbols because they have different error messages.

Open question: Should literals on the exported symbols list also be added to the symbol table as undefined symbols in order to pull definitions from archive inputs? It is unclear from my initial reading of ld64 sources. I'll look closer tomorrow and/or experiment.

lld/test/MachO/export-options.s
79

llvm-objdump --export-trie only prints the exported symbols, so the -NOT is necessary to catch an unexpected line for _hide_globl as TRIE-NOT. By contrast, llvm-nm -m prints a line for every symbol to report its visibility, and we already have a pattern asserting as expected non-external (was a private external).

gkm updated this revision to Diff 330171.Mar 12 2021, 12:37 AM
gkm marked 3 inline comments as done.
  • revise according to review feedback
int3 added inline comments.Mar 16 2021, 7:26 PM
lld/MachO/Driver.cpp
1040

unnecessary braces

lld/MachO/SymbolTable.cpp
19–22

this seems small enough to move into the header

lld/MachO/SyntheticSections.cpp
585–588

I'm wondering if this will be a performance bottleneck. If a build has mostly global symbols in the input but uses -exported_symbols to filter out most of them, then it would be better to set the value of privateExtern at parse time instead of calling exportedSymbols.match() more than once.

My measurements show that symbol ordering (which again looks up every symbol in a hashmap) is the biggest bottleneck when linking chromium_framework, so it wouldn't surprise me if this is worth optimizing.

We can punt on that for now though, but it would be good to leave a TODO

612

Please file a task re the open question if you're not getting to it soon :) It's a good case to consider, let's not forget about it

lld/test/MachO/export-options.s
30

IMO there's no point in matching this if we're not also matching the filename (I'm fine with just removing this line)

int3 accepted this revision.Mar 16 2021, 7:27 PM
This revision is now accepted and ready to land.Mar 16 2021, 7:27 PM
gkm marked 4 inline comments as done.Mar 16 2021, 8:55 PM