Summary:
Besides just generating and consuming the lists, this includes:
* Calling nm with the right options in extract_symbols.py. Such as not
demangling C++ names, which AIX nm does by default, and accepting both
32/64-bit names.
* Not having nm sort the list of symbols or we may run in to memory
issues on debug builds, as nm calls a 32-bit sort.
* Defaulting to having LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on for AIX
* CMake versions prior to 3.16 set the -brtl linker flag globally on
AIX. Clear it out early on so we don't run into failures. We will set
it as needed.
Reviewers: jasonliu, DiggerLin, stevewan, hubert.reinterpretcast
Reviewed By: hubert.reinterpretcast
Subscribers: hubert.reinterpretcast, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70972
Summary:
nm is one of the tools that extract_symbols.py can use to extract
symbols from llvm libraries as part of the build process. This patch
updates the invocation of nm to use the -P POSIX option for "portable
output" so we get a consistently parsable output format on all
platforms.
A link to the relevant nm format: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/nm.html
Reviewers: hubert.reinterpretcast, stevewan, sfertile
Reviewed By: stevewan
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69004
The existing logic was to discard any symbols representing function template
instantiations, as the definitions were assumed to be inline. But there are
three explicit specializations of clang::Type::getAs that are only defined in
Clang's lib/AST/Type.cpp, and at least the plugin used by the LibreOffice build
(https://wiki.documentfoundation.org/Development/Clang_plugins) uses those
functions.
Differential Revision: https://reviews.llvm.org/D26455
llvm-svn: 286841
This involved running 2to3 on it and adjusting all uses of subprocess to use
universal_newlines=True so the output is text instead of binary. It remains
compatible with Python 2.7.
llvm-svn: 274365
The problem with plugins on Windows is that when building a plugin DLL it needs
to explicitly link against something (an exe or DLL) if it uses symbols from
that thing, and that thing must explicitly export those symbols. Also there's a
limit of 65535 symbols that can be exported. This means that currently plugins
only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with
MSVC.
This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled
automatically exports from all LLVM tools the symbols that a plugin could want
to use so that a plugin can link against a tool directly. Plugins can specify
what tool they link against by using PLUGIN_TOOL argument to llvm_add_library.
The option can also be enabled on Linux, though there all it should do is
restrict the set of symbols that are exported as by default all symbols are
exported.
This option is currently OFF by default, as while I've verified that it works
with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no
idea what will happen on OSX. Also unfortunately we can't turn on
LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be
loaded by both bugpoint.exe and opt.exe which is incompatible with this
approach. Also currently clang plugins don't work with this approach, which
will be fixed in future patches.
Differential Revision: http://reviews.llvm.org/D18826
llvm-svn: 270839
