DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.

Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.

Differential revision: https://reviews.llvm.org/D57749

llvm-svn: 353293

GatherAllAliases only makes sense for LSBaseSDNode. Enforce it with
static typing instead of runtime cast.

llvm-svn: 353291

llvm-svn: 353290

Differential revision: https://reviews.llvm.org/D57517

llvm-svn: 353289

The wrong variable was being used when printing the address increment in
verbose output of .debug_line. This patch fixes this.

Reviewed by: JDevlieghere

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

llvm-svn: 353288

This patch adds half a dozen new tests that test various edge cases in
the behaviour of the symbolizer and DWARF data parsing. All of them test
the current behaviour.

Reviewed by: JDevlieghere, aprantl

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

llvm-svn: 353286

When a thunk is created to a PLT entry, the call to the thunk is converted
to a non-plt expression with fromPlt(). If the thunk becomes unusable we
retarget the relocation back to its original target and try again. When we
do this we need to make sure that we restore the PLT form of the expression
with toPlt().

This change adds a test case that will fail if toPlt() is removed. We need
to have a call to a preemptible symbol defined within the link unit. If
toPlt() is removed then the relocation to the thunk to the PLT entry for the
preemptible symbol will be retargeted to the preemptible symbol itself
instead of its PLT entry.

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

llvm-svn: 353285

Reviewers: sammccall

Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 353284

Reviewers: ilya-biryukov

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

Tags: #clang

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

llvm-svn: 353283

Summary:
llvm-exegesis uses this functionality to read it's benchmark dumps.
This reading of `.yaml`s takes ~60% of runtime for 14656 benchmark points (i.e. one sweep over all x86 instructions),
but only 30% of time for 3x as much benchmark points.

In particular, this `BinaryRef` appears to be an obvious pain point.
Without patch:
```
$ perf stat -r 25 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=1.0 -benchmarks-file=/tmp/benchmarks-inverse_throughput-onefull.yaml -analysis-clusters-output-file="" -analysis-inconsistencies-output-file=/tmp/clusters-orig.html
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-orig.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-orig.html'

 Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=1.0 -benchmarks-file=/tmp/benchmarks-inverse_throughput-onefull.yaml -analysis-clusters-output-file= -analysis-inconsistencies-output-file=/tmp/clusters-orig.html' (25 runs):

            972.86 msec task-clock                #    0.994 CPUs utilized            ( +-  0.25% )
                30      context-switches          #   30.774 M/sec                    ( +- 21.74% )
                 0      cpu-migrations            #    0.370 M/sec                    ( +- 67.81% )
             11873      page-faults               # 12211.512 M/sec                   ( +-  0.00% )
        3898373408      cycles                    # 4009682.186 GHz                   ( +-  0.25% )  (83.12%)
         360399748      stalled-cycles-frontend   #    9.24% frontend cycles idle     ( +-  0.54% )  (83.24%)
        1099450483      stalled-cycles-backend    #   28.20% backend cycles idle      ( +-  0.59% )  (33.63%)
        4910528820      instructions              #    1.26  insn per cycle
                                                  #    0.22  stalled cycles per insn  ( +-  0.13% )  (50.21%)
        1111976775      branches                  # 1143726625.854 M/sec              ( +-  0.10% )  (66.77%)
          23248474      branch-misses             #    2.09% of all branches          ( +-  0.19% )  (83.29%)

           0.97850 +- 0.00647 seconds time elapsed  ( +-  0.66% )
```
With the patch:
```
$ perf stat -r 25 ./bin/llvm-exegesis -mode=analysis -analysis-epsilon=1.0 -benchmarks-file=/tmp/benchmarks-inverse_throughput-onefull.yaml -analysis-clusters-output-file="" -analysis-inconsistencies-output-file=/tmp/clusters-new.html
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new.html'
...
no exegesis target for x86_64-unknown-linux-gnu, using default
Parsed 14656 benchmark points
Printing sched class consistency analysis results to file '/tmp/clusters-new.html'

 Performance counter stats for './bin/llvm-exegesis -mode=analysis -analysis-epsilon=1.0 -benchmarks-file=/tmp/benchmarks-inverse_throughput-onefull.yaml -analysis-clusters-output-file= -analysis-inconsistencies-output-file=/tmp/clusters-new.html' (25 runs):

            905.29 msec task-clock                #    0.999 CPUs utilized            ( +-  0.11% )
                15      context-switches          #   16.533 M/sec                    ( +- 32.27% )
                 0      cpu-migrations            #    0.000 K/sec
             11873      page-faults               # 13121.789 M/sec                   ( +-  0.00% )
        3627759720      cycles                    # 4009283.100 GHz                   ( +-  0.11% )  (83.19%)
         370401480      stalled-cycles-frontend   #   10.21% frontend cycles idle     ( +-  0.22% )  (83.19%)
        1007114438      stalled-cycles-backend    #   27.76% backend cycles idle      ( +-  0.34% )  (33.62%)
        4414014304      instructions              #    1.22  insn per cycle
                                                  #    0.23  stalled cycles per insn  ( +-  0.08% )  (50.36%)
        1003751700      branches                  # 1109314021.971 M/sec              ( +-  0.07% )  (66.97%)
          24611010      branch-misses             #    2.45% of all branches          ( +-  0.10% )  (83.41%)

           0.90593 +- 0.00105 seconds time elapsed  ( +-  0.12% )
```
So this decreases the overall run time of llvm-exegesis analysis mode (on one sweep) by roughly -7%.

To be noted, `BinaryRef::writeAsBinary()` change is the reason for the perf changes,
usage of `llvm::isHexDigit()` instead of `isxdigit()` does not appear to have any perf impact,
i have only changed it "for symmetry".

`writeAsBinary()` change is correct, it produces identical de-hex-ified buffer, and the final output is thus identical:
```
$ sha512sum /tmp/clusters-*
db4bbd904fe8840853b589b032c5041bc060b91bcd9c27b914b56581fbc473550eea74b852238c79963b5adf2419f379e9f5db76784048b48e3937f9f3e732bf  /tmp/clusters-new.html
db4bbd904fe8840853b589b032c5041bc060b91bcd9c27b914b56581fbc473550eea74b852238c79963b5adf2419f379e9f5db76784048b48e3937f9f3e732bf  /tmp/clusters-orig.html
```

Reviewers: silvas, espindola, sbc100, zturner, courbet, gchatelet

Reviewed By: gchatelet

Subscribers: tschuett, RKSimon, llvm-commits

Tags: #llvm

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

llvm-svn: 353282

instructions

Summary: This patch makes `x86AssemblyInspectionEngine` to process zero value of
the `B` field of the `REX` prefix in a correct way for `PUSH` and `POP`
instructions. MSVC sometimes emits `pushq %rbp` instruction as `0x40 0x55`, and
it was not parsed correctly before.

Reviewers: jasonmolenda, labath

Reviewed By: jasonmolenda, labath

Subscribers: abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 353281

LLDB testsuite fails when built by GCC8 on:
  LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp

This is because this code in LLDB codebase has undefined behavior:

  #include <algorithm>
  #include <string.h>
  // lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1731
  static struct section_64 {
    char sectname[16];
    char segname[16];
  } sect64 = { {'_','_','a','p','p','l','e','_','n','a','m','e','s','p','a','c'}, "__DWARF" };
  int main() {
    return std::min<size_t>(strlen(sect64.sectname), sizeof(sect64.sectname));
  }

It has been discussed as a (false) bugreport to GCC:
  wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp
  https://bugzilla.redhat.com/show_bug.cgi?id=1672436

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

llvm-svn: 353280

llvm-svn: 353278

llvm-svn: 353277

llvm-svn: 353276

llvm-svn: 353275

llvm-svn: 353274

llvm-svn: 353273

llvm-svn: 353272

This patch introduces a new tool called 'lldb-instr'. It automates the
workflow of inserting LLDB_RECORD and LLDB_REGSITER macros for
instrumentation.

Because the tool won't be part of the build process, I didn't want to
over-complicate it. SB_RECORD macros are inserted in place, while
SB_REGISTER macros are printed to stdout, and have to be manually copied
into the Registry's constructor. Additionally, the utility makes no
attempt to properly format the inserted macros. Please use clang-format
to format the changes after running the tool.

Differential revision: https://reviews.llvm.org/D56822

llvm-svn: 353271

Summary:
Follow up to D57082 which moved splitting earlier in the pipeline, in
order to perform it before inlining. However, it was moved too early,
before the IR is annotated with instrumented PGO data. This caused the
splitting to incorrectly determine cold functions.

Move it to just after PGO annotation (still before inlining), in both
pass managers.

Reviewers: vsk, hiraditya, sebpop

Subscribers: mehdi_amini, llvm-commits

Tags: #llvm

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

llvm-svn: 353270

if the size of the g packet response was smaller than expected and is
going to be ignored.

llvm-svn: 353269

Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.

This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.

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

llvm-svn: 353268

llvm-svn: 353267

llvm-svn: 353266

DomTreeUpdater depends on headers from Analysis, but is in IR.  This is a
layering violation since Analysis depends on IR.  Relocate this code from IR
to Analysis to fix the layering violation.

llvm-svn: 353265

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

llvm-svn: 353264

The definition is harmful here as it suppresses R_PPC64_REL24 which is
supposed to follow R_PPC64_TLSLD.

llvm-svn: 353263

Summary:
R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error.

R_PPC64_GOT_TLSGD16_HA
R_PPC64_GOT_TLSGD16_LO
R_PPC64_TLSGD R_TLSDESC_CALL
R_PPC64_REL24 __tls_get_addr

Reviewers: ruiu, sfertile, syzaara, espindola

Reviewed By: sfertile

Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur

Tags: #llvm

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

llvm-svn: 353262

llvm-svn: 353261

Reviewers: tlively

Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, cfe-commits

Tags: #clang

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

llvm-svn: 353260

llvm-svn: 353259

llvm-svn: 353258

Thanks Jonas...  One more early continue and using
a range where we had an iterator.

NFC

llvm-svn: 353257

Summary:
Refactor the way /proc/self/maps entries are annotated to support most
(all?) posix platforms, with a special implementation for Android.
Extend the set of decorated Mmap* calls.

Replace shm_open with internal_open("/dev/shm/%s"). Shm_open is
problematic because it calls libc open() which may be intercepted.

Generic implementation has limits (max number of files under /dev/shm is
64K on my machine), which can be conceivably reached when sanitizing
multiple programs at once. Android implemenation is essentially free, and
enabled by default.

The test in sanitizer_common is copied to hwasan and not reused directly
because hwasan fails way too many common tests at the moment.

Reviewers: pcc, vitalybuka

Subscribers: srhines, kubamracek, jfb, llvm-commits, kcc

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

llvm-svn: 353255

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

llvm-svn: 353254

llvm-svn: 353251

In a previous patch, I made changes so that PDBs which were
generated on non-Windows platforms contained sensical paths
for the host.  While this is an esoteric use case, we need
it to be supported for certain cross compilation scenarios
especially with LLDB, which can debug things on non-Windows
platforms.

However, this regressed a case where you specify /PDBSOURCEPATH
and use a windows-style path.  Previously, we would still remove
dots and canonicalize slashes to backslashes, but since my
change intentionally tried to support non-backslash paths, this
was broken.

This patch fixes the situation by trying to guess which path
style the user is specifying when /PDBSOURCEPATH is passed.
It is intentionally conservative, erring on the side of a
Windows path style unless absolutely certain.  All dots are
removed and slashes canonicalized to whatever the deduced
path style is after appending the file path to the /PDBSOURCEPATH
argument.

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

llvm-svn: 353250

llvm-svn: 353249

Summary:
- Delete {} for one-line `let` statements
- Don't indent within `let` blocks
- Add comments after `let` block's closing braces

Reviewers: tlively

Subscribers: dschuff, sbc100, jgravelle-google, sunfish, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 353248