[llvm-dev] Orc JIT vs. STL

[Praveen Velliengiri via llvm-dev]

AFAIK, GetForCurrentProcess method uses getPermanentLibrary rather than
LoadLibraryPermanently.

On Tue, 27 Aug 2019 at 21:15, Geoff Levner <glevner at gmail.com> wrote:

> I don't have the DynamicLibrarySearchGenerator and
> StaticLibrarySearchGenerator classes. I should mention that we are
> using LLVM 7... Does
> DynamicLibrarySearchGenerator::GetForCurrentProcess() do more than
> what DynamicLibrary::LoadLibraryPermanently(nullptr) does (or did)?
>
> I am also thinking our problems might be connected to the fact that
> gcc 6.3.1 is in a software collection (devtoolset-6) and that there is
> some sort of  magic going on to mix its STL (the .a file) with the
> libstdc++ DSO, which is in /usr/lib64, not in devtoolset-6.
>
> On Tue, Aug 27, 2019 at 5:36 PM Praveen Velliengiri
> <praveenvelliengiri at gmail.com> wrote:
> >
> > You can add symbols from Archieve via StaticLibrarySearchGenerator. But
> it is added recently though
> >
> > On Tue, 27 Aug 2019 at 21:02, Praveen Velliengiri <
> praveenvelliengiri at gmail.com> wrote:
> >>
> >> Hi Geoff,
> >> I tried it, but I can't able to reproduce it.
> >>
> >> Test Program:
> >> #include <fstream>
> >> int main()
> >> {
> >>  std::ifstream stream1, stream2;
> >>  stream1.swap(stream2);
> >>  return 0;
> >> }
> >>
> >> I didn't get undefined symbols error. I used
> DynamicLibrarySearchGenerator::GetForCurrentProcess API to make symbols
> from STL visible to ORC JIT.
> >>
> >> On Tue, 27 Aug 2019 at 20:36, Geoff Levner <glevner at gmail.com> wrote:
> >>>
> >>> On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri
> >>> <praveenvelliengiri at gmail.com> wrote:
> >>> >
> >>> > HI
> >>> > Did you run the static constructor and destructor? How did you make
> your process symbols visible to ORC jit?
> >>>
> >>> Yes. It's the constructor that generates the undefined symbol error.
> >>> We use DynamicLibrary::LoadLibraryPermanently(nullptr) to add process
> >>> symbols.
> >>>
> >>> > Could you please share us the for what symbols you get undefined
> references :-)
> >>>
> >>> Certainly! Mangled:
> >>>
> >>>     _ZNSi4swapERSi
> >>>     _ZNSt13basic_filebufIcSt11char_traitsIcEE4swapERS2_
> >>>
> >>> And unmangled:
> >>>
> >>>     std::basic_istream<char, std::char_traits<char>
> >>> >::swap(std::basic_istream<char, std::char_traits<char> >&)
> >>>     std::basic_filebuf<char, std::char_traits<char>
> >>> >::swap(std::basic_filebuf<char, std::char_traits<char> >&)
> >>>
> >>> Incidentally, if I call that STL swap() function in the application,
> >>> to ensure it is in the process symbols, the second symbol is found,
> >>> but the first is still undefined.
> >>>
> >>>
> >>> >
> >>> > On Aug 27, 2019 8:18 PM, "Geoff Levner via llvm-dev" <
> llvm-dev at lists.llvm.org> wrote:
> >>> >>
> >>> >> Greetings, LLVM wizards.
> >>> >>
> >>> >> We are using Clang and Orc JIT (v1) to compile and execute C++ code
> on the fly. If a C++ module calls functions from external libraries, we add
> them via DynamicLibrary::LoadLibraryPermanently().
> >>> >>
> >>> >> The problem we have run into recently is when a module calls a
> function from the STL -- in particular this swap() function for input
> streams:
> >>> >>
> >>> >> #include <fstream>
> >>> >> std::ifstream stream1, stream2;
> >>> >> stream1.swap(stream2);
> >>> >>
> >>> >> When we run the constructors for the module, we get two undefined
> symbols. And explicitly adding libstdc++ doesn't help. It turns out that
> the missing symbols are defined not in the runtime DSO but in an archive
> file:
> >>> >>
> >>> >>
> /opt/rh/devtoolset-6/root/usr/lib/gcc/x86_64-redhat-linux/6.3.1/libstdc++.a
> >>> >>
> >>> >> So my questions are:
> >>> >>
> >>> >> 1. Is there a simple way to get access to all symbols defined in
> the STL? Intuitively, it seems like we should not need to know about such
> compiler magic.
> >>> >>
> >>> >> 2. If there is no magical solution, is there a way to explicitly
> add symbols from an archive?
> >>> >>
> >>> >> Thanks,
> >>> >> Geoff
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> LLVM Developers mailing list
> >>> >> llvm-dev at lists.llvm.org
> >>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190827/961bcd24/attachment.html>