Summary:
We're using the clang static analyzer together with a number of
custom analyses in our CI system to ensure that certain invariants
are statiesfied for by the code every commit. Unfortunately, there
currently doesn't seem to be a good way to determine whether any
analyzer warnings were emitted, other than parsing clang's output
(or using scan-build, which then in turn parses clang's output).
As a simpler mechanism, simply add a `-analyzer-werror` flag to CC1
that causes the analyzer to emit its warnings as errors instead.
I briefly tried to have this be `Werror=analyzer` and make it go
through that machinery instead, but that seemed more trouble than
it was worth in terms of conflicting with options to the actual build
and special cases that would be required to circumvent the analyzers
usual attempts to quiet non-analyzer warnings. This is simple and it
works well.
Reviewed-By: NoQ, Szelethusw
Differential Revision: https://reviews.llvm.org/D62885
llvm-svn: 362855
Summary: Move some code around, in preparation for later fixes
to the non-integral addrspace handling (D59661)
Patch By Jameson Nash <jameson@juliacomputing.com>
Reviewed By: reames, loladiro
Differential Revision: https://reviews.llvm.org/D59729
llvm-svn: 362853
Summary:
When handling exports from the command line or from .def files, the
linker does a "fuzzy" string lookup to allow finding mangled symbols.
However, when the symbol is re-exported under a new name, the linker has
to transfer the decorations from the exported symbol over to the new
name. This is implemented by taking the mangled symbol that was found in
the object and replacing the original symbol name with the export name.
Before this patch, LLD implemented the fuzzy search by adding an
undefined symbol with the unmangled name, and then during symbol
resolution, checking if similar mangled symbols had been added after the
last round of symbol resolution. If so, LLD makes the original symbol a
weak alias of the mangled symbol. Later, to get the original symbol
name, LLD would look through the weak alias and forward it on to the
import library writer, which copies the symbol decorations. This
approach doesn't work when bar is itself a weak alias, as is the case in
asan. It's especially bad when the aliasee of bar contains the string
"bar", consider "bar_default". In this case, we would end up exporting
the symbol "foo_default" when we should've exported just "foo".
To fix this, don't look through weak aliases to find the mangled name.
Save the mangled name earlier during fuzzy symbol lookup.
Fixes PR42074
Reviewers: mstorsjo, ruiu
Subscribers: thakis, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62984
llvm-svn: 362849
Add docs (llvm-lipo.rst) for llvm-lipo.
Test plan:
make -j8 sphinx
check that ./docs/html/CommandGuide/llvm-lipo.html is built correctly and looks okay.
Differential revision: https://reviews.llvm.org/D62706
llvm-svn: 362848
Summary:
This fixes the bugzilla id,41862 to support dealing with checking
stop address against start address to support this not being a
proper object to check the disasembly against like gnu objdump
currently does.
Reviewers: jakehehrlich, rupprecht, echristo, jhenderson, grimar
Reviewed By: jhenderson
Subscribers: MaskRay, smeenai, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61969
Patch by Nicholas Krause!
llvm-svn: 362847
In LLDB, where tests run with the debug version of Python, we get a
series of deprecation warnings because escape sequences like `\(` are
being treated as part of the string literal rather than an escape for
the regexp pattern.
NFC intended.
Differential Revision: https://reviews.llvm.org/D62882
llvm-svn: 362846
Problem discovered in the breakpoint lit test, but probably exists in others.
lldb-test splits lines on LF. Input files that are CR+LF separated (as is
common on Windows) then resulted in commands being sent to LLDB that ended
in CR, which confused the command interpreter.
This could be fixed at different levels:
1. Treat '\r' like a tab or space in the argument splitter.
2. Fix the line splitters (plural) in lldb-test.
3. Normalize the test files to LF only.
If we did only 3, I'd expect similar problems to recur, so this patch does
1 and 2. I may also do 3 in a separate patch later, but that's tricky
because I believe we have some input files that MUST use CR+LF.
Differential Revision: https://reviews.llvm.org/D62759
llvm-svn: 362844
lldb/lit/SymbolFile/DWARF/debug-types-expressions.test fails with msan.
This change fixes the issue by ensuring FileNameEntry::checksum is
always default-initialized.
llvm-svn: 362843
Summary:
Longstanding issues in the Android test runner means that compiler-rt unit
tests don't work on Android due to libc++ link-time issues. Looks like the
exported libc++ from the Android NDK is x86-64, even though it's part of the
ARM[64] toolchain... See similar measures for ASan and sanitizer-common that
disable unit tests for Android.
Should fully fix the Android bots (@vlad.tsyrklevich).
Reviewers: vitalybuka
Reviewed By: vitalybuka
Subscribers: srhines, kubamracek, mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits, vlad.tsyrklevich
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63019
llvm-svn: 362842
Displays the architecture names of an input file.
Unknown architectures are represented by unknown(cputype,cpusubtype).
Patch by Anusha Basana <anusha.basana@gmail.com>
Differential Revision: https://reviews.llvm.org/D62753
llvm-svn: 362840
Summary:
The cleanup in D62751 introduced a compile-time regression due to the way DT updates are performed.
Add all insert edges then all delete edges in DTU to match the previous compile time.
Compile time on the test provided by @mstorsjo before and after this patch on my machine:
113.046s vs 35.649s
Repro: clang -target x86_64-w64-mingw32 -c -O3 glew-preproc.c; on https://martin.st/temp/glew-preproc.c.
Reviewers: kuhar, NutshellySima, mstorsjo
Subscribers: jlebar, mstorsjo, dmgreen, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62981
llvm-svn: 362839
rather than two callbacks.
The asynchronous lookup API (which the synchronous lookup API wraps for
convenience) used to take two callbacks: OnResolved (called once all requested
symbols had an address assigned) and OnReady to be called once all requested
symbols were safe to access). This patch updates the asynchronous lookup API to
take a single 'OnComplete' callback and a required state (SymbolState) to
determine when the callback should be made. This simplifies the common use case
(where the client is interested in a specific state) and will generalize neatly
as new states are introduced to track runtime initialization of symbols.
Clients who were making use of both callbacks in a single query will now need to
issue two queries (one for SymbolState::Resolved and another for
SymbolState::Ready). Synchronous lookup API clients who were explicitly passing
the WaitOnReady argument will now need neeed to pass a SymbolState instead (for
'WaitOnReady == true' use SymbolState::Ready, for 'WaitOnReady == false' use
SymbolState::Resolved). Synchronous lookup API clients who were using default
arugment values should see no change.
llvm-svn: 362832
We create several types of synthetic sections for loadable partitions, including:
- The dynamic symbol table. This allows code outside of the loadable partitions
to find entry points with dlsym.
- Creating a dynamic symbol table also requires the creation of several other
synthetic sections for the partition, such as the dynamic table and hash table
sections.
- The partition's ELF header is represented as a synthetic section in the
combined output file, and will be used by llvm-objcopy to extract partitions.
Differential Revision: https://reviews.llvm.org/D62350
llvm-svn: 362819
This implements the functionality described in
https://lld.llvm.org/Partitions.html. It works as follows:
- Reads the section headers using the ELF header at file offset 0;
- If extracting a loadable partition:
- Finds the section containing the required partition ELF header by looking it up in the section table;
- Reads the ELF and program headers from the section.
- If extracting the main partition:
- Reads the ELF and program headers from file offset 0.
- Filters the section table according to which sections are in the program headers that it read:
- If ParentSegment != nullptr or section is not SHF_ALLOC, then it goes in.
- Sections containing partition ELF headers or program headers are excluded as there are no headers for these in ordinary ELF files.
Differential Revision: https://reviews.llvm.org/D62364
llvm-svn: 362818
Summary:
Add output to `llvm::errs()` when `-ftime-trace` option is enabled,
add regression test checking this option works as expected.
Reviewers: thakis, aganea
Subscribers: cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61914
........
Breaks buildbots - @anton-afanasyev please can you take a look?
llvm-svn: 362816
Before this patch we used either a single thread, or the number of
hardware threads available, effectively ignoring the number of threads
specified on the command line.
llvm-svn: 362815
On the Command Guide page, there are multiple sections with links to the
different documentation pages available for LLVM tools. The "Basic
Tools" section includes tools like llvm-objdump, llvm-nm and so on. The
"Developer Tools" section contains things like FileCheck and lit. This
change moves llvm-readobj into the former block, from the latter.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D63011
llvm-svn: 362813
Summary:
We currently return an error, this causes `coc.nvim` and VSCode to
show an error message in the logs.
Returning empty list of completions allows to avod the error message
without altering other user-visible behavior.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62999
llvm-svn: 362811
llvm-lib now needs a `target triple` for bitcode, so add a new file
that's like trivial.ll but has one, and use that in the test.
(trivial.ll had a comment that looked like it wasn't supposed to be used
in tests directly, so I don't want to change that file.)
llvm-svn: 362809
Summary:
It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open
and POSIX compatibility mode, to work around stray macros and other
bugs in the headers provided by the system and build compiler.
This patch adds the config to cmake to build with _XOPEN_SOURCE defined
on AIX with a few exceptions. Google Test internals require access to
platform specific thread info constructs on AIX so in that case we build
with _ALL_SOURCE defined instead. Libclang also uses header which needs
_ALL_SOURCE on AIX so we leave that as is as well.
We also add building on AIX with the large file API and doing CMake
header checks with X/OPEN definitions so the results are consistent with
the environment that will be present in the build.
Reviewers: hubert.reinterpretcast, xingxue, andusy
Reviewed By: hubert.reinterpretcast
Subscribers: mgorny, jsji, cfe-commits, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D62533
llvm-svn: 362808
If MVE is present at all, then the macro __ARM_FEATURE_MVE is defined
to a value which has bit 0 set for integer MVE, and bit 1 set for
floating-point MVE.
(Floating-point MVE implies integer MVE, so if this macro is defined
at all then it will be set to 1 or 3, never 2.)
Patch mostly by Simon Tatham
Differential Revision: https://reviews.llvm.org/D60710
llvm-svn: 362806
When we call checkResourceLimit in bumpCycle or bumpNode, and we
know the resource count has just reached the limit (the equations
are equal). We should return true to mark that we are resource
limited for next schedule, or else we might continue to schedule
in favor of latency for 1 more schedule and create a schedule that
actually overbook the resource.
When we call checkResourceLimit to estimate the resource limite before
scheduling, we don't need to return true even if the equations are
equal, as it shouldn't limit the schedule for it .
Differential Revision: https://reviews.llvm.org/D62345
llvm-svn: 362805
Summary:
Allow to run the test suite when building LLDB Standalone with Xcode against a provided LLVM build-tree that used a single-configuration generator like Ninja.
So far both test drivers, lit-based `check-lldb` as well as `lldb-dotest`, were looking for test dependencies (clang/dsymutil/etc.) in a subdirectory with the configuration name (Debug/Release/etc.). It was implicitly assuming that both, LLDB and the provided LLVM used the same generator. In practice, however, the opposite is quite common: build the dependencies with Ninja and LLDB with Xcode for development*. With this patch it becomes the default.
(* In fact, it turned out that the Xcode<->Xcode variant didn't even build out of the box. It's fixed since D62879)
Once this is sound, I'm planning the following steps:
* add stage to the [lldb-cmake-standalone bot](http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/) to build and test it
* update `Building LLDB with Xcode` section in the docs
* bring the same mechanism to swift-lldb
* fade out the manually maintained Xcode project
On macOS build and test like this:
```
$ git clone https://github.com/llvm/llvm-project.git /path/to/llvm-project
$ cd /path/to/lldb-dev-deps
$ cmake -GNinja -C/path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi" /path/to/llvm-project/llvm
$ ninja
$ cd /path/to/lldb-dev-xcode
$ cmake -GXcode -C/path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake -DLLDB_BUILD_FRAMEWORK=Off -DLLVM_DIR=/path/to/lldb-dev-deps/lib/cmake/llvm -DClang_DIR=/path/to/lldb-dev-deps/lib/cmake/clang /path/to/llvm-project/lldb
$ xcodebuild -configuration Debug -target check-lldb
$ xcodebuild -configuration Debug -target lldb-dotest
$ ./Debug/bin/lldb-dotest
```
Reviewers: JDevlieghere, jingham, xiaobai, stella.stamenova, labath
Reviewed By: stella.stamenova
Subscribers: labath, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62859
llvm-svn: 362803
Keno Fischer