Have the Progress class spawn a thread to periodically send progress
reports.
The reporting period could be made configurable, but for now I've
hardcoded it to 100ms. (This is the main WIP part)
It could be argued that creating a thread for progress reporting adds
overhead, but I would counter that by saying "If the task is so fast
that creating a thread noticably slows it down, then it really doesn't
need progress reporting".
For me, this speeds up DWARF indexing by about 1.5% (which is only
slightly above the error bars), but I expect it will have a much bigger
impact in situations where printing a single progress update takes a
nontrivial amount of time.
Differential Revision: https://reviews.llvm.org/D152364
If `evaluateAsAbsolute(Value, Layout.getAssembler())` returns true, we
know the address delta is a constant and can suppress relocations
(usually SET6/SUB6).
While here, replace two evaluateKnownAbsolute calls (subtle; avoid if possible)
with evaluateAsAbsolute.
Currently, lldb's unwinder ignores cfi_restore opcodes for registers
that are not set in the first row of the unwinding info. This prevents
unwinding of failed assertion in Chrome/v8 (https://github.com/v8/v8).
The attached test is an x64 copy of v8's function that failed to unwind
correctly (V8_Fatal).
This patch changes handling of cfi_restore to reset the location if
the first unwind table row does not map the restored register.
Differential Revision: https://reviews.llvm.org/D153043
Building the given test case with 'clang -O2 -g' the call to
'getInOrder' is sunk out of the loop by LICM, but the source
location is not dropped.
Reviewed By: aprantl, fdeazeve
Differential Revision: https://reviews.llvm.org/D152691
D152712 replaced `llvm::sys::RetryAfterSignal(-1, ::open)` with
`FileSystem::Instance().Open` for bionic in PseudoTerminal::OpenSecondary, and
FileSystem::Instance() is failing with assertion on arm Linux.
The assertion should be FileSystem re-initialization check, therefore the
hypothesis is that TerminalTest tests are initializing FileSystem instance
repeatedly.
Use SubsystemRAII<FileSystem> to ensure tearing down the FileSystem instance.
Differential Revision: https://reviews.llvm.org/D153091
Use range-based for loops.
The return type has been changed to bool because the method is only
used in boolean contexts.
Reviewed By: mtrofin
Differential Revision: https://reviews.llvm.org/D152665
Turn MC*RegIterator into fully qualified iterators by deriving them from
iterator_adaptor_base. This makes mc_*_reg iterators redundant.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D152655
To aid in integration testing/debugging. Verifying that the address
mask/addressable bits values from different sources are correctly
registered by lldb.
We can make the table for the `tosa.cast` permissible operations readable by utilizing the markdown table format.
{F27924602}
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D152992
We prevent merging a sparse-in/dense-out with dense-in
kernels because the result is usuall not sparsifiable.
Dense kernels and sparse kernels are still fused, obviously.
Reviewed By: Peiming
Differential Revision: https://reviews.llvm.org/D153077
Scudo has zero-tagged headers between any two allocation that will catch
a linear buffer overflow of up to 16 bytes. OddEvenTags extends this
guarantee to one chunk of the given SizeClass at the cost of the reduced
entropy for all heap tags (i.e. lower chance to catch use-after-free and
large overflows).
Given that the first 16 bytes are already deterministic, I feel this is
a bad tradeoff.
Differential Revision: https://reviews.llvm.org/D152984
Due to logic in the 64-bit allocator, the smallest allocation we can
zx_vmar_allocate is 2^37 bytes, but this is too large to allocate for
the standalone lsan allocator on a 39-bit VMA. This leads to the
zx_vmar_allocate call when initially setting up the allocator to fail.
This is similar to what android experiences on a 64-bit system with a
small vma. (See sanitizer_allocator_test.cpp).
This effectively reverts f6c4808d95221a5838e14474d95c6fe85bb1488a and
has Fuchsia use the 32-bit allocator for RISCV.
This was a result of copy/paste from the MMAP interceptor which uses the parameter to swtich between mmap and mmap64.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D152980
On one CI bot we're seeing a failure where the kernel reports that
we have completed an instruction step (via a mach exception) and
lldb doesn't think the thread was doing an instruction step. It
takes the conservative approach of stopping at this point, breaking
tests.
This patch adds an llvm fatal error for debug builds where it will
log the state of the thread and the AArch64 ESR, to confirm what
the hardware reported as the exception so we can double check the
kernel's interpretation.
I'll change this to an lldbassert without the runtime details in
the string once we have an idea what is happening. the hope is
that this will get hit on the CI bot soon.
Differential Revision: https://reviews.llvm.org/D153079
Create a new PagesInfo to contain all the information about pages. This
is the preparation of adding new lock for page operations.
Note that primary32 hasn't switched to MemMap. Will add PagesInfo later
when we move to MemMap in primary32.
Differential Revision: https://reviews.llvm.org/D149142
Create a new BlocksInfo to contain a list of blocks, poppedBlocks and
pushedBlocks. This is the preparation of adding new lock for operations
on freelist.
Differential Revision: https://reviews.llvm.org/D149143
We were producing inconsistent results when a file appeared multiple
times in gcno/gcda files if the instances had differing relative paths.
This patch unifies filenames, so coverage results are merged.
Patch by Oleksii Odynochenko. Thanks!
Differential Revision: https://reviews.llvm.org/D152453
None of these need to be in the ConstString StringPool. For the most
part they are constant strings and do not require fast comparisons.
I did change IOHandlerDelegateMultiline slightly -- specifically, the
`m_end_line` member always has a `\n` at the end of it now. This was so
that `IOHandlerGetControlSequence` can always return a StringRef. This
did require a slight change to `IOHandlerIsInputComplete` where we must
drop the newline before comparing it against the input parameter.
Differential Revision: https://reviews.llvm.org/D151597
Currently, `SectionFileAddressesChanged` clears out the `name_to_index`
map and sets `m_file_addr_to_index_compute` to false. This is strange,
as these two fields are used for different purposes. What we should be
doing is clearing the file address to index mapping.
There are 2 bugs here:
1. If we call SectionFileAddressesChanged after the name indexes have
been computed, we end up with an empty name to index map, so lookups
will fail. This doesn't happen today because we don't initialize the
name indexes before calling this, but this is a refactor away from
failing in this way.
2. Because we don't clear `m_file_addr_to_index` but still set it's
computed flag to false, it ends up with twice the amount of
information. One entry will be correct (since it was recalculated),
one entry will be outdated.
rdar://110192434
Differential Revision: https://reviews.llvm.org/D152579
lldb-server for Android does not build with NDK r21 and above due to
RetryAfterSignal and Bionic ::open mismatch.
https://github.com/llvm/llvm-project/issues/54727
Apply the LLVM patch to LLDB.
0a0e411204
> In Bionic, open can be overloaded for _FORTIFY_SOURCE support, causing
> compile errors of RetryAfterSignal due to overload resolution. Wrapping
> the call in a lambda avoids this.
Differential Revision: https://reviews.llvm.org/D152712
A vmv.v.i/x splats the immediate to all active lanes. For the active lanes, this is the same as vmv.s.x which inserts one scalar into the low lane. If we can ignore all the inactive lanes (because they are known undefined), then the two are semantically equivalent. We already reason about compatible VL/VTYPE combinations for vmv.s.x, apply the same logic to vmv.v.i.
Unlike a vmv.s.x, we do need to be careful not to increase LMUL. A splat instruction is probably linear in LMUL, so restrict this to LMUL1.
Differential Revision: https://reviews.llvm.org/D152845
Instead of setting the SimplifyCFGOptions options at the beginning of the pass.
Otherwise it always gets overriden by the pass and the value in SimplifyCFGOptions is ignored.
Switching to this interface we neglected to actually write the output
from the malloc call to the RPC buffer. Fix this so the tests pass
again.
Differential Revision: https://reviews.llvm.org/D153069
