[PATCH] D142188: [ORC] Fix in-process lookup of symbols without GlobalPrefix

Tue Jan 24 09:48:58 PST 2023

lhames added a comment.

In D142188#4076374 <https://reviews.llvm.org/D142188#4076374>, @Hahnfeld wrote:

> Sure, but is this actually relevant? Passing `foo` is not properly mangled and an error on the client side.

It's not an error: ORC lookups are always made in terms of raw symbol names (which we often refer to as "linker mangled"). The impedance mismatch in DynamicLibrarySearchGenerator comes from the fact that `dlsym` does not work with raw names, it works with C names, which will have been mangled with a leading underscore.

As an example, consider a JIT'd program consisting of two JITDylibs. JITDylib A contains an object built from assembly containing the label "foo" (no underscore, which is legal -- this isn't a C symbol). JITDylib B contains a DynamicLibraryDefinitionGenerator pointing at an on-disk libB.dylib which contains an `_foo` (presumably defined in C). A lookup with search order `[ A, B ]` for symbols `[ "foo", "_foo" ]` should find a result for "foo" from JITDylib A, and "_foo" from JITDylib B (where the result will have come from demangling "_foo" to "foo", then calling dlsym).

> *If* it is required to make this robust against all possible edge cases, we have to make fairly intrusive changes as shown in the last update to pass `DataLayout::doNotMangleLeadingQuestionMark()` to `DynamicLibrarySearchGenerator` (or require a `DataLayout` in the first place, but that's a bigger restriction IMO).

As mentione, a good option for now would be to replace GlobalPrefix with a unique_function that takes a SymbolStringPtr and produces an optionally demangled string suitable for the platform's dynamic-symbol-lookup API.

Alternatively, maybe it's time to just add a DataLayout (or global default mangling and demangling functions) to `ExecutionSession` and let everybody reference that.

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

https://reviews.llvm.org/D142188