When used in cross-DSO mode, CFI will generate calls to special functions rather than trap instructions.  For example, instead of generating

if (!InlinedFastCheck(f))
  abort();
call *f

CFI generates

if (!InlinedFastCheck(f))
  __cfi_slowpath(CallSiteTypeId, f);
call *f

This patch teaches cfi-verify to recognize calls to __cfi_slowpath and abort and treat them as trap functions.

In addition to normal symbols, we also parse the dynamic relocations to handle cross-DSO calls in libraries.

We also extend cfi-verify to recognize other patterns that occur using cross-DSO.  For example, some indirect calls are not guarded by a branch to a trap but instead follow a call to __cfi_slowpath.  For example:

if (!InlinedFastCheck(f))
  call *f
else {
  __cfi_slowpath(CallSiteTypeId, f);
  call *f
}

In this case, the second call to f is not marked as protected by the current code.  We thus recognize if indirect calls directly follow a call to a function that will trap on CFI violations and treat them as protected.

We also ignore indirect calls in the PLT, since on AArch64 each entry contains an indirect call that should not be protected by CFI, and these are labeled incorrectly when debug information is not present.

Differential Revision: https://reviews.llvm.org/D49383

llvm-svn: 340612

Differential Revision: https://reviews.llvm.org/D50204

llvm-svn: 340611

This adds a new method to ELFObjectFileBase that returns the symbols and addresses of PLT entries.

This design was suggested by pcc and eugenis in https://reviews.llvm.org/D49383.

Differential Revision: https://reviews.llvm.org/D50203

llvm-svn: 340610

Summary:
This commit fixes a regression introduced in r316095, where we don't match
inverted character classes when there's no negated characrers in the []'s.

rdar://problem/43060054

Reviewers: mclow.lists, timshen, EricWF

Subscribers: christof, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D50534

llvm-svn: 340609

Summary:
The state associated to the future was set in one thread (with synchronization)
but read in another thread without synchronization, which led to a data race.

https://bugs.llvm.org/show_bug.cgi?id=38181
rdar://problem/42548261

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D51170

llvm-svn: 340608

Reviewers: ilya-biryukov, ioeric, hokein

Reviewed By: ilya-biryukov

Subscribers: mgorny, ioeric, MaskRay, jkorous, arphaman, jfb, cfe-commits

Differential Revision: https://reviews.llvm.org/D50502

llvm-svn: 340607

This patch makes the DoesKMove argument non-optional, to force people
to think about it. Most cases where it is false are either code hoisting
or code sinking, where we pick one instruction from a set of
equal instructions among different code paths.

Reviewers: dberlin, nlopes, efriedma, davide

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D47475

llvm-svn: 340606

This patch introduces LIMIT iterator, which is very important for
improving the quality of search query. LIMIT iterators can be applied on
top of BOOST iterators to prevent populating query request with a huge
number of low-quality symbols.

Reviewed by: sammccall

Differential Revision: https://reviews.llvm.org/D51029

llvm-svn: 340605

Summary:
For index-based code completion, send an asynchronous speculative index
request, based on the index request for the last code completion on the same
file and the filter text typed before the cursor, before sema code completion
is invoked. This can reduce the code completion latency (by roughly latency of
sema code completion) if the speculative request is the same as the one
generated for the ongoing code completion from sema. As a sequence of code
completions often have the same scopes and proximity paths etc, this should be
effective for a number of code completions.

Trace with speculative index request:{F6997544}

Reviewers: hokein, ilya-biryukov

Reviewed By: ilya-biryukov

Subscribers: javed.absar, jfb, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D50962

llvm-svn: 340604

This patch splits the file trace loading function into two versions, one
that takes a filename and one that takes a `DataExtractor`.

This change is a precursor to larger changes to increase test coverage
for the trace loading implementation.

llvm-svn: 340603

Revert to the original behavior: only calculate real file path when
file is opened and avoid using InterndPath for real path calculation.

llvm-svn: 340602

This patch prints information about built index size estimation to
verbose logs. This is useful for optimizing memory usage of DexIndex and
comparisons with MemIndex.

Reviewed by: sammccall

Differential Revision: https://reviews.llvm.org/D51154

llvm-svn: 340601

Summary:
The new mode avoids serializing and deserializing YAML.
This results in better performance and less memory usage. Reduce phase
is now almost instant.

The default is to use the old mode going through YAML serialization to
allow migrating MapReduce clients that require the old mode to operate
properly. After we migrate the clients, we can switch the default to
the new mode.

Reviewers: hokein, ioeric, kbobyrev, sammccall

Reviewed By: ioeric

Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D51155

llvm-svn: 340600

Summary:
Used in clangd's symbol builder to optimize for the common
shared-memory executor case.

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D51164

llvm-svn: 340599

Summary:
This partially rolls back the change in D48903:
https://github.com/llvm-mirror/clang/commit/89aa7f45a1f728144935289d4ce69d8522999de0#diff-0025af005307891b5429b6a834823d5eR318

`real_path` can be very expensive on real file systems, and calling it on each
opened file can slow down the compilation. This also slows down deserialized
ASTs for which real paths need to be recalculated for each input files again.

For clangd code completion latency (using preamble):
Before
{F7039629}
After
{F7039630}

Reviewers: ilya-biryukov, simark

Reviewed By: ilya-biryukov

Subscribers: kadircet, cfe-commits

Differential Revision: https://reviews.llvm.org/D51159

llvm-svn: 340598

Summary:
`variables.test` depends on mangled names, but the mangling depends
on the bitness. This patch specifies the bitness explicitly, so mangled names
doesn't differ when a 32-bit version of the compiler is used.

Reviewers: stella.stamenova, asmith

Reviewed By: stella.stamenova

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D51158

llvm-svn: 340597

This updates the test case for r340519 so it should pass again. r340522
only got some of the AVR tests that needed an update.

llvm-svn: 340596

Reviewers: asb, apazos, mgrang

Reviewed By: asb

Differential Revision: https://reviews.llvm.org/D50043

llvm-svn: 340595

Having the KnownBits as an output parameter is kind of awkward to use
and a holdover from when it was two separate APInts. Instead, just
return a KnownBits object.

I'm leaving the existing interface in place for now, since updating
the callers all at once would be thousands of lines of diff.

llvm-svn: 340594

llvm-svn: 340593

Per LLVM's CommandGuide, llvm-profdata show -text is supposed to produce
textual output that can be passed as input to further llvm-profdata
invocations. This previously didn't work for two reasons:

1) -text was not sufficient to enable the machine-readable text format output;
instead, -text was effectively ignored if -counts was not also specified. (With
this patch, -counts is instead ignored if -text is specified, because the
machine-readable text format always includes counts.)

2) When the input data was an IR-level profile, the :ir marker was missing from
the output, resulting in a text format output that would not be usable as
profiling data due to function hash mismatches.

Differential Revision: https://reviews.llvm.org/D51188

llvm-svn: 340592

llvm-svn: 340591

I removed the ".exe" regex in the wrong place. lld-link in front of the
"error:" no longer has the suffix; the --plugin-opt diagnostic still has it.

llvm-svn: 340590

Summary:
The DirCompletionAbsolute is still randomly failing on the nodes even after D50722, so this patch adds more asserts
that verify certain properties on which the actual completion implementation relies on.

The first assert checks that the directory we complete on actually exists. If the directory doesn't exist on the
next CI failure, this assert should catch it and we know that the 0 matches come from a missing base directory.

The second assert is just checking that we are below the PATH_MAX limit that the completion checks against.
This check could randomly fail if the temporary directories we generate are sometimes longer than PATH_MAX,
and the assert can tell us that this is the reason we failed (instead of the mysterious '0 matches').

(As a sidenote: We shouldn't be checking against PATH_MAX anyway in the code (as this is just wrong). Also
the disk completion API really needs a better error mechanism than returning 0 on both error or no-results.)

Reviewers: aprantl, friss

Reviewed By: aprantl

Subscribers: abidh

Differential Revision: https://reviews.llvm.org/D51111

llvm-svn: 340589

That way users can set the default to true, but then disable core dumps
from certain apps that link support.

llvm-svn: 340588

Calling task_for_pid with mach_task_self is just returning mach_task_self anyway, but it also triggers system warnings (task_for_pid is only supposed to be used by high-privileged executables). NFC.

rdar://problem/39198248

Differential Revision: https://reviews.llvm.org/D51119

llvm-svn: 340587

llvm-svn: 340586

Summary:
At the moment we create our own SelectorTable even though the Preprocessor always
creates one for us that we can (and should) reuse.

Reviewers: vsk

Reviewed By: vsk

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D51185

llvm-svn: 340585

Fix a set of related bugs:

* Considering two locations as equivalent when their lines are the same
but their scopes are different causes erroneous debug info that
attributes a commoned call to be attributed to one of the two calls it
was commoned from.

* The previous code to compute a new location's scope was inaccurate and
would use the inlinedAt that was the /parent/ of the inlinedAt that is
the nearest common one, and also used that parent scope instead of the
nearest common scope.

* Not generating new locations generally seemed like a lower quality
choice

There was some risk that generating more new locations could hurt object
size by making more fine grained line table entries, but it looks like
that was offset by the decrease in line table (& address & ranges) size
caused by more accurately computing the scope - which likely lead to
fewer range entries (more contiguous ranges) & reduced size that way.

All up with these changes I saw minor reductions (-1.21%, -1.77%) in
.rela.debug_ranges and .rela.debug_addr (in a fission, compressed debug
info build) as well as other minor size changes (generally reductinos)
across the board (-1.32% debug_info.dwo, -1.28% debug_loc.dwo). Measured
in an optimized (-O2) build of the clang binary.

If you are investigating a size regression in an optimized debug builds,
this is certainly a patch to look into - and I'd be happy to look into
any major regressions found & see what we can do to address them.

llvm-svn: 340583

llvm-svn: 340581

Again, this required adding some const specifiers.

llvm-svn: 340580

Received multiple reports of breakage due to undefined symbols
suspected to be caused by this change.

llvm-svn: 340579

1. The dynamic loaders should not be needed for loading minidumps
and they may create problems (ex. the macOS loader resets the list of
loaded sections, which for minidumps are already set up during minidump loading)

2. In general, the extra plugins can do extraneous work which hurts performance
(ex. trying to set up implicit symbolic breakpoints, which in turn will trigger
extra debug information loading)

Differential Revision: https://reviews.llvm.org/D51176

llvm-svn: 340578

In order for more complex updates of MSSA to happen (e.g. those in
D45299), MemoryDefs need to be actual `Use`s of what they're optimized
to. This patch makes that happen.

In addition, this patch changes our optimization behavior for Defs
slightly: we'll now consider a Def optimization invalid if the
MemoryAccess it's optimized to changes. That we weren't doing this
before was a bug, but given that we were tracking these with a WeakVH
before, it was sort of difficult for that to matter.

We're already have both of these behaviors for MemoryUses. The
difference is that a MemoryUse's defining access is always its optimized
access, and defining accesses are always `Use`s (in the LLVM sense).

Nothing exploded when testing a stage3 clang+llvm locally, so...

This also includes the test-case promised in r340461.

llvm-svn: 340577

Summary:
`MmapNoAccess` & `MmapFixedNoAccess` return directly the result of
`internal_mmap`, as opposed to other Mmap functions that return nullptr.

This inconsistency leads to some confusion for the callers, as some check for
`~(uptr)0` (`MAP_FAILED`) for failure (while it can fail with `-ENOMEM` for
example).

Two potential solutions: change the callers, or make the functions return
`nullptr` on failure to follow the precedent set by the other functions.
The second option looked more appropriate to me.

Correct the callers that were wrongly checking for `~(uptr)0` or
`MAP_FAILED`.

TODO for follow up CLs:
- There are a couple of `internal_mmap` calls in XRay that check for
  MMAP_FAILED as a result as well (cc: @dberris); they should use
  `internal_iserror`;


Reviewers: eugenis, alekseyshl, dberris, kubamracek

Reviewed By: alekseyshl

Subscribers: kristina, kubamracek, delcypher, #sanitizers, dberris, llvm-commits

Differential Revision: https://reviews.llvm.org/D50940

llvm-svn: 340576

This required adding a few const specifiers on functions.

Also a minor formatting fix suggested in D49885.

llvm-svn: 340575

right and doesn't add much signal.

llvm-svn: 340574

llvm-svn: 340573

Lower integer arguments smaller than i32.
Support both register and stack arguments.
Define setLocInfo function for setting LocInfo field in ArgLocs vector.

Patch by Petar Avramovic.

Differential Revision: https://reviews.llvm.org/D51031

llvm-svn: 340572

Summary:
Calling any non-libc builtin function in the expression command currently just causes Clang
to state that the function is not known. The reason for this is that we actually never
initialize the list of builtin functions in the Builtin::Context.

This patch just calls the initializer for the builtins in the preprocessor. Also adds some tests
for the new builtins.

It also gets rid of the extra list of builtins in the ClangExpressionParser, as we can just reuse
the existing list in the Preprocessor for the ASTContext. Having just one list of builtins around
is also closer to the standard Clang behavior.

Reviewers: #lldb, vsk

Reviewed By: vsk

Subscribers: sgraenitz, clayborg, vsk, lldb-commits

Differential Revision: https://reviews.llvm.org/D50481

llvm-svn: 340571