This addresses the issue introduced in r361432 where we would only
try effective triple but not the normalized one as we do for other
runtimes.
Differential Revision: https://reviews.llvm.org/D62286
llvm-svn: 361504
Summary:
On Windows `lldb::thread_result_t` resolves to `typedef unsigned thread_result_t;` and on other platforms it resolves to `typedef void *thread_result_t;`.
Therefore one cannot use `nullptr` when returning from a function that returns `thread_result_t`.
I've made this change because a windows build bot fails with these errors:
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
and
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
This is the failing build: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5035/steps/build/logs/stdio
Reviewers: JDevlieghere, teemperor, jankratochvil, labath, clayborg, RKSimon, courbet, jhenderson
Reviewed By: labath, clayborg
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62305
llvm-svn: 361503
Using a static function as a template parameter gets a bogus compile-time
error with Visual Studio 2017, prior to version 15.8. Our current
minimum-version requirement is a particular update to VS2015, and we
assume all Visual Studio 2017 versions are usable. This patch makes the
code buildable with older versions of VS2017, and can be reverted after
we upgrade the minimum version sometime in the future.
Description of the Microsoft bug:
https://developercommunity.visualstudio.com/content/problem/25334/error-code-c2971-when-specifying-a-function-as-the.html
Differential Revision: https://reviews.llvm.org/D62202
llvm-svn: 361502
which doesn't play well with passing CMAKE_MAKE_PROGRAM from the
commandline without a path.
Fixes a bug introduced in r361280.
Thanks to Mikael Holmén for reporting this!
llvm-svn: 361501
This patch adds the pseudo instructions la.tls.ie and la.tls.gd, used in
the initial-exec and global-dynamic TLS models respectively when
addressing a global. The pseudo instructions are expanded in the
assembly parser.
llvm-svn: 361499
Class LSUnitBase provides a abstract interface for all the concrete LS units in
llvm-mca.
Methods exposed by the public abstract LSUnitBase interface are:
- Status isAvailable(const InstRef&);
- void dispatch(const InstRef &);
- const InstRef &isReady(const InstRef &);
LSUnitBase standardises the API, but not the data structures internally used by
LS units. This allows for more flexibility.
Previously, only method `isReady()` was declared virtual by class LSUnit.
Also, derived classes had to inherit all the internal data members of LSUnit.
No functional change intended.
llvm-svn: 361496
Some tests assume that iteration through an unordered multiset elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return
elements exactly from a set of valid values and without repetition,
but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56500
llvm-svn: 361494
This change renames a number of the disassembly tests to standardise
disasm/diassemble/disassembly to disassemble. Requested in
https://reviews.llvm.org/D62255.
llvm-svn: 361491
This is the third commit in a series of patches to improve test coverage
of llvm-objdump. In this patch I have added a number of tests testing
various aspects of disassembly.
Reviewed by: MaskRay, grimar, rupprecht
Differential Revision: https://reviews.llvm.org/D62255
llvm-svn: 361489
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
Refactor location description kind in order to be easier for extensions
(needed for D60866).
In addition, cut off some bits from the other class fields.
Patch by Djordje Todorovic.
Differential Revision: https://reviews.llvm.org/D62002
llvm-svn: 361480
This patch focuses on adding additional testing for the --source switch.
For reference, the source-interleave-x86_64.ll test file has been split
into two parts - the input (shared with the other tests) and the test
itself.
Reviewed by: MaskRay, rupprecht, grimar
Differential Revision: https://reviews.llvm.org/D61996
llvm-svn: 361479
Summary:
Clangd is already resolving symlinks on the server side, therefore
there is no more need to handle it in client side. This was also resulting in
breakages whenever index contained a symbol coming from a non-existent file(like
a generated file), e.g. during workspace symbols whole response was dropped
since stat had failed.
Reviewers: ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62288
llvm-svn: 361475
My recent commits separated symbol resolution from the symbol table,
so the functions to resolve symbols are now in a somewhat wrong file.
This patch moves it to Symbols.cpp.
The functions are now member functions of the symbol.
This is code move change. I modified function names so that they are
appropriate as member functions, though. No functionality change
intended.
Differential Revision: https://reviews.llvm.org/D62290
llvm-svn: 361474
--{start,end}-lib give files grouped by the options the archive file
semantics. That is, each object file between them acts as if it were
in an archive file whose sole member is the file.
Therefore, files between --{start,end}-lib are linked to the final
output only if they are needed to resolve some undefined symbols.
Previously, the feature was implemented this way:
1. We read a symbol table and insert defined symbols to the symbol
table as lazy symbols.
2. If an undefind symbol is resolved to a lazy symbol, that lazy
symbol instantiate ObjFile class for that symbol, which re-insert
all defined symbols to the symbol table.
So, if an ObjFile is instantiated, defined symbols are inserted to the
symbol table twice. Since inserting long symbol names is not cheap,
there's a room to optimize here.
This patch optimzies it. Now, LazyObjFile remembers symbol handles and
passed them over to a new ObjFile instance, so that the ObjFile
doesn't insert the same strings.
Here is a quick benchmark to link clang. "Original" is the original
lld with unmodified command line options. For "Case 1" and "Case 2", I
extracted all files from archive files and replace .a's in a command
line with .o's wrapped with --{start,end}-lib. I used the original lld
for Case 1" and use this patch for Case 2.
Original: 5.892
Case 1: 6.001 (+1.8%)
Case 2: 5.701 (-3.2%)
So, interestingly, --{start,end}-lib are now faster than the regular
linking scheme with archive files. That's perhaps not too surprising,
though, because for regular archive files, we look up the symbol table
with the same string twice.
Differential Revision: https://reviews.llvm.org/D62188
llvm-svn: 361473
This is a minor improvement inspired by https://bugs.llvm.org/show_bug.cgi?id=38303.
A person reported that he observed message complaining about unsupported R_ARM_V4BX:
error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC
But with -z notext he only saw a relocation number, what is not convenient:
error: ../../gfx/cairo/libpixman/src/pixman-arm-neon-asm-bilinear.o:(.text+0x4F0): unrecognized reloc 40
Also, in the error messages we use relocation but not reloc.
With this patch we start to print one of the following messages:
error: file.o: unrecognized relocation Unknown(999)
error: file.o: unrecognized relocation R_X_KNOWN_BY_LLVM_BUT_UNSUPPORTED_BY_LLD_NAME
There is no way to write a test for that I believe.
Differential revision: https://reviews.llvm.org/D62237
llvm-svn: 361472
Summary:
Before we can assign entries in the function of global index space
we need to know the total number of function and global imports
respectively.
To avoid programmer error this change seals that imports section before
assigned function and global index space. Any attempt to add an import
after the section is sealed will assert.
The lack this such as check caused https://reviews.llvm.org/D61876
to be reverted. I'm also trying to craft a test case the this
failure.
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62240
llvm-svn: 361470
Also renames it LinkerDriver::compileBitcodeFiles.
The function doesn't logically belong to SymbolTable. We added this
function to the symbol table because symbol table used to be a
container of input files. This is no longer the case.
Differential Revision: https://reviews.llvm.org/D62291
llvm-svn: 361469
Support queue_t and clk_event_t comparisons in C++ for OpenCL mode, to
preserve backwards compatibility with OpenCL C.
Differential Revision: https://reviews.llvm.org/D62208
llvm-svn: 361467
The code in ELF/Object.cpp is sometimes a bit hard to read because of
lots of auto used everywhere. The main intention of this patch is
to replace them with the real type for places where it is not obvious.
Also it cleanups few places.
It is NFC change, but I want to be sure that there is no objections to do that since it
is massive.
DIfferential revision: https://reviews.llvm.org/D62260
llvm-svn: 361466
Summary:
Type units don't describe any code, so they should never be the result
of any address lookup queries.
Previously, we would compute the address ranges for the type units for
via the line tables they reference because the type units looked a lot
like line-tables-only compile units. However, this is not correct, as
the line tables are only referenced from type units so that other
declarations can use the file names contained in them.
In this patch I make the BuildAddressRangeTable function virtual, and
implement it only for compile units.
Testing this was a bit tricky, because the behavior depends on the order
in which we add things to the address range map. This rarely caused a
problem with DWARF v4 type units, as they are always added after all
CUs. It happened more frequently with DWARF v5, as there clang emits the
type units first. However, this is still not something that it is
required to do, so for testing I've created an assembly file where I've
deliberately sandwiched a compile unit between two type units, which
should isolate us from both changes in how the compiler emits the units
and changes in the order we process them.
Reviewers: clayborg, aprantl, JDevlieghere
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D62178
llvm-svn: 361465
In D61502#1503247 @clayborg suggested that DWARFUnit *+dw_offset_t can be now
replaced by DWARFDIE.
It is moved from DWARFDebugInfoEntry to DWARFDIE as noted by @clayborg.
I have also removed return type as (1) it was wrong in one case and (2) no
existing caller used the return type. I also refactored the deep nesting noted
by @JDevlieghere.
Differential Revision: https://reviews.llvm.org/D62211
llvm-svn: 361463
The previous patch added a member set to store instructions that we
could allow to wrap. But this wasn't cleared between searches meaning
that they could get promoted, incorrectly, during the promotion of a
separate valid chain.
Differential Revision: https://reviews.llvm.org/D62254
llvm-svn: 361462
Summary:
Allow struct fields SRA and dead stores. This works by considering fields accesses from getElementPtr to be considered as a possible pointer root that can be cleaned up.
We check that the variable can be SRA by recursively checking the sub expressions with the new isSafeSubSROAGEP function.
basically this allows the array in following C code to be optimized out
struct Expr {
int a[2];
int b;
};
static struct Expr e;
int foo (int i)
{
e.b = 2;
e.a[i] = 1;
return e.b;
}
Reviewers: greened, bkramer, nicholas, jmolloy
Reviewed By: jmolloy
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61911
llvm-svn: 361460
Replaces the remaining C-style casts with explicit casts in Utility. The
motivation is that they are (1) easier to spot and (2) don't have
multiple meanings.
llvm-svn: 361458
It's uncommon to rely on temporary lifetime extension when having a
regular, non-`const&` value behaves identically. Since `Twine::str`
and `buildFixMsgForStringFlag` both return regular `std::string`s,
there's seemingly no point in having `const&` here.
llvm-svn: 361457
This ensures that whether the user uses short or cannonical version
of the triple, Clang will still find the runtimes under the cannonical
triple name.
Differential Revision: https://reviews.llvm.org/D52132
llvm-svn: 361456
Petr Hosek