Summary:
The test (among other things) attempts to verify that detaching works while the inferior is
running. However, this was racy since the inferior could end up stopping again before we got a
chance to detach from it (the test could be made to fail reliably by inserting a sleep just after
the last "continue" command). The reason for the stop was that we had a breakpoint set in a place
that can be hit by multiple threads, and we stop because another thread hit a breakpoint.
I fix this by moving the breakpoint to a place that is reachable from only one thread. I also
make sure that the same thread cannot hit the breakpoint if we are exceptionaly slow by flipping
a flag which makes the breakpoint unreachable (I cannot just disable or delete the breakpoint as
the test makes it a point to try detaching while breakpoints are still set).
Another source or racyness was that the test verified that the process resumes and
stops after a "continue". However, if these two events happened too fast, the initial start event
would be lost, and the test would end up confused. I have implemented this in a safer manner and
made a utility function out of it, as I know of a couple of other tests which need the same
functionality.
Reviewers: zturner, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12527
llvm-svn: 246623
Vector 'getelementptr' with scalar base is an opportunity for gather/scatter intrinsic to generate a better sequence.
While looking for uniform base, we want to use the scalar base pointer of GEP, if exists.
Differential Revision: http://reviews.llvm.org/D11121
llvm-svn: 246622
I don't understand why the previous code is pretty flaky and
the new code is at least less flaky, but the original test
occasionally failed on the second run of lib.exe.
My guess was that lib.exe was failing because the output of
the echo command executed immediately before lib.exe was not
flushed to a file, but as far as I can say, the file
descriptor is properly closed in TestRunner.py, so this's
probably not correct. Other theory is that, on Windows, file
output is not guaranteed to be visible to other processes even
if a process flushes file descriptors, but I'd think that's
unlikely. So honestly I don't know the cause yet.
llvm-svn: 246621
This patch fixes a subtle incompatibility with MSVC linker.
MSVC linker preserves the original spelling of a DLL in the
import descriptor table. LLD previously converted all
characters to lowercase. Usually this difference is benign,
but if a program explicitly checks for DLL file names, the
program could fail.
llvm-svn: 246620
These are useful helpers over the low-level API of the FormattersContainer, and since we're actually going to start moving formatters into plugins, it makes sense to simplify things
llvm-svn: 246612
the main attribute and cache the results so we don't have to parse
a single attribute more than once.
This reapplies r246596 with a fix for an uninitialized class member,
and a couple of cleanups and formatting changes.
llvm-svn: 246610
Summary:
When calling find_first_of and find_last_of on a single character,
we can instead just call find / rfind and make our intent more
clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12518
llvm-svn: 246609
Summary:
This was removed from the other ABI plugins long ago. This removes
a warning that was happening in this unused code as a result of
adding 2 new types to Scalar.h (e_uint128 and e_sint128).
Reviewers: clayborg
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12514
llvm-svn: 246608
The MS incremental linker seems to inspect the timestamp written into
the object file to determine whether or not it's contents need to be
considered. Failing to set the timestamp to a date newer than the
executable will result in the object file not participating in
subsequent links. To ameliorate this, write the current time into the
object file's TimeDateStamp field.
llvm-svn: 246607
Summary:
Comparing m_page_size against kInvalidPageSize was resulting in
a warning about comparing integers with different signs. Since
kInvalidPageSize isn't used anywhere outside of MachVMMemory.cpp,
we can readily transform it into a static const vm_size_t with
the correct value to avoid the sign comparison warnings.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12519
llvm-svn: 246606
Summary:
This was previously only established within debugserver, but
there is a use of the VLA extension in source/Host/macosx/Symbols.cpp,
so ignore this warning globally.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12515
llvm-svn: 246605
We can just ask the ObjectWriter for it's stream instead of caching
around our own reference to it. No functionality change is intended.
llvm-svn: 246604
The ELF spec says:
... if any reference to or definition of a name is a symbol with a
non-default visibility attribute, the visibility attribute must be
propagated to the resolving symbol in the linked object. If different
visibility attributes are specified for distinct references to or
definitions of a symbol, the most constraining visibility attribute
must be propagated to the resolving symbol in the linked object. The
attributes, ordered from least to most constraining, are:
STV_PROTECTED, STV_HIDDEN and STV_INTERNAL.
llvm-svn: 246603
Summary:
`OpaqueValueExpr`s may not have a source expression (as in the case when
they are created due to a default argument error).
This can cause an assertion failure in `TransformOpaqueValueExpr` during
template instantiation.
This patch fixes the assertion failure.
Reviewers: hfinkel, rsmith
Subscribers: fraggamuffin, cfe-commits
Differential Revision: http://reviews.llvm.org/D11582
Patch by Rachel Craik!
llvm-svn: 246600
The code introduced in r244314 assumed that EXTRACT_VECTOR_ELT only
takes constant indices, but it does accept variables.
Bail out for those: we can't use them, as the shuffles we want to
reconstruct do require constant masks.
llvm-svn: 246594
COFF sections are accompanied with an auxiliary symbol which includes a
checksum. This checksum used to be filled with just zero but this seems
to upset LINK.exe when it is processing a /INCREMENTAL link job.
Instead, fill the CheckSum field with the JamCRC of the section
contents. This matches MSVC's behavior.
This fixes PR19666.
N.B. A rather simple implementation of JamCRC is given. It implements
a byte-wise calculation using the method given by Sarwate. There are
implementations with higher throughput like slice-by-eight and making
use of PCLMULQDQ. We can switch to one of those techniques if it turns
out to be a significant use of time.
llvm-svn: 246590
Parallelism can be enabled using a new plugin option, jobs=N, where N is
the number of code generation threads.
Differential Revision: http://reviews.llvm.org/D12308
llvm-svn: 246584
r246546, with a workaround for an MSVC 2013 miscompile and an MSVC 2015
rejects-valid.
Original commit message:
[modules] Rework serialized DeclContext lookup table management. Instead of
walking the loaded ModuleFiles looking for lookup tables for the context, store
them all in one place, and merge them together if we find we have too many
(currently, more than 4). If we do merge, include the merged form in our
serialized lookup table, so that downstream readers never need to look at our
imports' tables.
This gives a huge performance improvement to builds with very large numbers of
modules (in some cases, more than a 2x speedup was observed).
llvm-svn: 246582
Pavel Labath