Summary:
If target.preload-symbols is false, waiting for the process to "stop"
can take an arbitrarily long amount of time, because it will cause all
the debug info to be parsed (to compute the stop message showing the
function, its arguments, etc).
We were previously waiting for 10 seconds for the stop even to arrive,
which is a pretty long time, but it's not that hard to overcome with
huge debug info.
Since any arbitrary limit can be theoretically overcome with huge
debug_info and/or slow machine, and the stop even was sent 3 lines above
the wait, if we ever do not receive the stop even means we've got a bug
in lldb. Therefore, I remove the timeout on this wait completely.
No test because I don't know how to reproduce this without a
multi-gigabyte symbol file.
Reviewers: jingham, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D63730
llvm-svn: 364276
This is a follow up to D56781, D56774 and D35077 to makes the LLVM-C.dll
file and LLVM-C.lib be installed on Windows, just like LTO.dll and
LTO.lib are.
Patch by Jakob Bornecrantz!
Differential revision: https://reviews.llvm.org/D63717
llvm-svn: 364275
Summary:
With the last round of refactors, supporting type units in dwo files
becomes almost trivial. This patch contains a couple of small fixes,
which taken as a whole make type units work in the split dwarf scenario
(both DWARF4 and DWARF5):
- DWARFContext: make sure we actually read the debug_types.dwo section
- DWARFUnit: set string offsets base on all units in the dwo file, not
just the main CU
- ManualDWARFIndex: index all units in the file
- SymbolFileDWARFDwo: Search for the single compile unit in the file, as
we can no longer assume it will be the first one
The last part makes it obvious that there is still some work to be done
here, namely that we do not support dwo files with multiple compile
units. That is something that should be easier after the DIERef
refactors, but it still requires more work.
Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as
well as a test that checks we behave reasonably in the presence of dwo
files with multiple CUs.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63643
llvm-svn: 364274
r360841 introduced CommonSymbol class. An unintended behavioral change
introduced by that change was that common symbols are not internalized
by LTO under some condition. This patch fixes that issue.
The issue occurred under the following condition:
1. There exists a common symbol
2. At least one DSO is given to lld or -pie is used
If the above conditions are met, Symbol::includeInDynsym() returned a
wrong value for a common symbol.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41978
Differential Revision: https://reviews.llvm.org/D63752
llvm-svn: 364273
I've been trying to fix this, but hit some roadblocks. So I'm
committing the test case for now so we'll at least avoid
recreating that failure.
llvm-svn: 364272
Diff support included.
A cheap solution is implemented that treats range constraints as
"some sort of key-value map", so it's going to be trivial
to add support for other such maps later, such as dynamic type info.
Differential Revision: https://reviews.llvm.org/D63685
llvm-svn: 364268
The -analyzer-stats flag now allows you to find out how much time was spent
on AST-based analysis and on path-sensitive analysis and, separately,
on bug visitors, as they're occasionally a performance problem on their own.
The total timer wasn't useful because there's anyway a total time printed out.
Remove it.
Differential Revision: https://reviews.llvm.org/D63227
llvm-svn: 364266
This reverts the following patches.
"[TargetLowering] SimplifyDemandedBits SIGN_EXTEND_VECTOR_INREG -> ANY/ZERO_EXTEND_VECTOR_INREG"
"[TargetLowering] SimplifyDemandedBits ZERO_EXTEND_VECTOR_INREG -> ANY_EXTEND_VECTOR_INREG"
"[TargetLowering] SimplifyDemandedBits - add ANY_EXTEND_VECTOR_INREG support"
We can end up with an any_extend_vector_inreg with a 256 bit result type
and a 128 bit result type. This is allowed by the ISD opcode, but the
generic operation legalizer is only able to expand cases where the
total vector width is the same.
The X86 backend creates these mismatched cases for zext_vec_inreg/sext_vec_inreg.
The SimplifyDemandedBits changes are allowing those nodes to become
aext_vec_inreg. For the zext/sext cases, the X86 backend has Custom
handling and never lets them get to the generic legalizer. We need to do the same
for aext_vec_inreg.
llvm-svn: 364264
Summary:
After evaluation it would be an Unknown value and tracking would be lost.
Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus
Reviewed By: NoQ
Subscribers: szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy,
dkrupp, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63720
llvm-svn: 364259
Summary:
Use an enum instead of string to hold the output file format in Config.InputFormat and Config.OutputFormat. It's essential to support other output file formats other than ELF.
Reviewers: espindola, alexshap, rupprecht, jhenderson
Reviewed By: rupprecht, jhenderson
Subscribers: jyknight, compnerd, emaste, arichardson, fedor.sergeev, jakehehrlich, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63239
llvm-svn: 364254
Should've been NFC, but turns out DataExtractor had better test coverage
for decoding SLEB128 than the decodeSLEB128 did - revealing a couple of
bugs (one in the error handling, another in sign extension). So fixed
those to get the DataExtractor tests passing again.
llvm-svn: 364253
This is the Demorgan'd 'not' of the pattern handled in:
D63660 / rL364153
This is another intermediate IR step towards solving PR42314:
https://bugs.llvm.org/show_bug.cgi?id=42314
We can test if a value is not a power-of-2 using ctpop(X) > 1,
so combining that with an is-zero check of the input is the
same as testing if not exactly 1 bit is set:
(X == 0) || (ctpop(X) u> 1) --> ctpop(X) != 1
llvm-svn: 364246
+ dlsym the two functions we need from there at runtime.
I'm not maintaining a negative cache if DebugSymbols is absent, so
we'll try to dlopen() it on every call to
LocateMacOSXFilesUsingDebugSymbols but this file is only built on
mac and iOS type systems, so there's a slight perf impact running
lldb on an iOS type system.
I store the function pointer results in two global variables without
any locking; two threads calling into LocateMacOSXFilesUsingDebugSymbols
for the first time will both try to set these fptrs, but they'll be
setting them to the same value, so I'm not too worried.
I didn't see where in the cmake build configurations we link against
DebugSymbols, but I removed the dependency from the xcode project
file.
<rdar://problem/49458356>
llvm-svn: 364243
Summary:
This change makes sure we have a single mapping for each macro expansion,
even if the result of expansion was empty.
To achieve that, we take information from PPCallbacks::MacroExpands into
account. Previously we relied only on source locations of expanded tokens.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62953
llvm-svn: 364236
Summary:
User code can open a file on its own and pass it to the runtime, rather than
specifying a name and having the runtime open the file. This supports the use
case where a process cannot open a file on its own but can receive a file
descriptor from another process.
Relanding https://reviews.llvm.org/D62541. The original revision unlocked
the file before calling flush, this revision fixes that.
Reviewers: Dor1s, davidxl
Reviewed By: Dor1s
Subscribers: #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D63581
llvm-svn: 364231
Summary:
It's possible that each LanguageRuntime could have its own DeclVendor,
so let's hoist that out of ObjCLanguageRuntime into LanguageRuntime.
Additionally, this gives the opportunity to remove SBTarget's dependency
on ObjCLanguageRuntime.
Reviewers: JDevlieghere, labath, compnerd, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63622
llvm-svn: 364229
Inference of nowrap flags in CVP has been disabled, because it
triggered a bug in LFTR (https://bugs.llvm.org/show_bug.cgi?id=31181).
This issue has been fixed in D60935, so we should be able to reenable
nowrap flag inference now.
Differential Revision: https://reviews.llvm.org/D62776
llvm-svn: 364228
Rather than create JSON objects for source locations and ranges, we instead stream them out directly. This allows us to elide duplicate information (without JSON field reordering causing an issue) like file names and line numbers, similar to the text dump. This also adds token length information when dumping the source location.
llvm-svn: 364226
This command prints a description of the referenced function's stack frame.
For each formal parameter and local variable, the tool prints:
- function name
- variable name
- file/line of declaration
- FP-relative variable location (if available)
- size in bytes
- HWASAN tag offset
This information will be used by the HWASAN runtime to identify local
variables in UAR reports.
Differential Revision: https://reviews.llvm.org/D63468
llvm-svn: 364225
Hiroshi Inoue