Two functions in the `is_32bit_windows` family were retrieving the
output of a tool via `subprocess.check_output`, and then iterating
over it using `for line in output`. But in Python, that gets you the
output one //character// at a time, not a line at a time. So the
regexes that looked for a platform name were never matching.
(This is a mistake that Python makes uniquely easy, because iterating
over a file and over a string have different default behaviour, and
because the element type of a string is still a string so you don't
even get a type mismatch error to warn you about it!)
Reviewed By: michaelplatings
Differential Revision: https://reviews.llvm.org/D117030
As of D105532, a couple of llvm-readobj options have slightly changed
their spellings. '-file-headers' has become '--file-header', and
'-symbols' has become '--symbols'. A modern llvm-readobj will respond
to those single-dash spellings by trying to parse them as combinations
of single-letter options, so that you get "unknown argument '-f'" for
-file-headers, and "unknown argument '-y'" for the second letter of
-symbols.
extract_symbols.py was still invoking llvm-readobj with those old
single-dash spellings. Changed them to the newly canonical ones, which
as far as I can tell still work on llvm-readobj from before the
change.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D113556
On AIX, we are currently relying on `objdump` to detemine the
is_32_bit_windows.
`objdump` is not installed by default on AIX, it is creating problem to
depend on it, especially just for an always false detection on AIX.
So this patch simply provide a always false function to satify the
detection.
Reviewed By: #powerpc, daltenty
Differential Revision: https://reviews.llvm.org/D112952
nm does not show size for aliased symbols,
we should still extract them if they are external.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D107112
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
Simon Tatham