| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the UnwindPlan did not identify how to unwind the stack pointer
register, LLDB currently assumes it can determine to caller's SP
from the current frame's CFA. This is true on most platforms
where CFA is by definition equal to the incoming SP at function
entry.
However, on the s390x target, we instead define the CFA to equal
the incoming SP plus an offset of 160 bytes. This is because
our ABI defines that the caller has to provide a register save
area of size 160 bytes. This area is allocated by the caller,
but is considered part of the callee's stack frame, and therefore
the CFA is defined as pointing to the top of this area.
In order to make this work on s390x, this patch introduces a new
ABI callback GetFallbackRegisterLocation that provides platform-
specific fallback register locations for unwinding. The existing
code to handle SP unwinding as well as volatile registers is moved
into the default implementation of that ABI callback, to allow
targets where that implementation is incorrect to override it.
This patch in itself is a no-op for all existing platforms.
But it is a pre-requisite for adding s390x support.
Differential Revision: http://reviews.llvm.org/D18977
llvm-svn: 266307
|
|
|
|
|
|
|
|
|
|
|
| |
OutputSectionFactory::lookup().
That was removed in r266304, but leads to warnings by Clang.
Thanks to Rafael Espíndola for pointing on that.
Though I think change was legal from point of C++.
llvm-svn: 266306
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PS_STRINGS constant can easily be incorrect with mismatched
kernel/userland - e.g. when building i386 sanitizers on FreeBSD/amd64
with -m32. The kern.ps_strings sysctl was introduced over 20 years ago
as the supported way to fetch the environment and argument string
addresses from the kernel, so the fallback is never used.
Differential Revision: http://reviews.llvm.org/D19027
llvm-svn: 266305
|
|
|
|
|
|
|
| |
Also I removed the last zero parameter of
aggregate initialization as it is excessive here.
llvm-svn: 266304
|
|
|
|
| |
llvm-svn: 266303
|
|
|
|
| |
llvm-svn: 266302
|
|
|
|
|
|
|
|
|
|
| |
Alias 'jic $reg, 0' to 'jrc $reg' and 'jialc $reg, 0' to 'jalrc $reg' like
binutils.
This patch was previous committed as r266055 as seemed to have caused some spurious
test failures. They did not reappear after further local testing.
llvm-svn: 266301
|
|
|
|
|
|
| |
This reverts commit r266294, as it broke some buildbots again. :/
llvm-svn: 266300
|
|
|
|
| |
llvm-svn: 266299
|
|
|
|
| |
llvm-svn: 266298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In short, CVE-2016-2143 will crash the machine if a process uses both >4TB
virtual addresses and fork(). ASan, TSan, and MSan will, by necessity, map
a sizable chunk of virtual address space, which is much larger than 4TB.
Even worse, sanitizers will always use fork() for llvm-symbolizer when a bug
is detected. Disable all three by aborting on process initialization if
the running kernel version is not known to contain a fix.
Unfortunately, there's no reliable way to detect the fix without crashing
the kernel. So, we rely on whitelisting - I've included a list of upstream
kernel versions that will work. In case someone uses a distribution kernel
or applied the fix themselves, an override switch is also included.
Differential Revision: http://reviews.llvm.org/D18915
llvm-svn: 266297
|
|
|
|
|
|
|
|
|
| |
This teaches sanitizer_common about s390 and s390x virtual space size.
s390 is unusual in that it has 31-bit virtual space.
Differential Revision: http://reviews.llvm.org/D18896
llvm-svn: 266296
|
|
|
|
|
|
|
|
|
|
| |
mmap on s390 is quite a special snowflake: since it has too many
parameters to pass them in registers, it passes a pointer to a struct
with all the parameters instead.
Differential Revision: http://reviews.llvm.org/D18889
llvm-svn: 266295
|
|
|
|
|
|
|
|
|
| |
Using stderr more uniformily, avoiding potential races when scanning stdout
and stderr output.
Patch by Maxim Kuvyrkov.
llvm-svn: 266294
|
|
|
|
| |
llvm-svn: 266293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce ASTImporter unit test framework.
Fix a memory leak introduced in cf8ccff5: an array is allocated
in ImportArray and never freed.
Support new node kinds:
- GCCAsmStmt
- AddrLabelExpr
- AtomicExpr
- CompoundLiteralExpr
- CXXBoolLiteralExpr
- CXXNullPtrLiteralExpr
- CXXThisExpr
- DesignatedInitExpr
- GNUNullExpr
- ImplicitValueInitExpr
- InitListExpr
- OpaqueValueExpr
- PredefinedExpr
- ParenListExpr
- StmtExpr
- VAArgExpr
- BinaryConditionalOperator
- ConditionalOperator
- FloatingLiteral
- StringLiteral
- InjectedClassNameType
- TemplateTypeParmType
- LabelDecl
Patch by Aleksei Sidorin!
Differential Revision: http://reviews.llvm.org/D14286
llvm-svn: 266292
|
|
|
|
|
|
|
|
|
|
|
| |
Some bots failed with:
sanitizer_quarantine.h:104:7: error: unused typedef 'assertion_failed__104' [-Werror,-Wunused-local-typedef]
COMPILER_CHECK(kPrefetch <= ARRAY_SIZE(b->batch));
Replace COMPILER_CHECK with CHECK.
llvm-svn: 266291
|
|
|
|
| |
llvm-svn: 266290
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18757
llvm-svn: 266289
|
|
|
|
| |
llvm-svn: 266288
|
|
|
|
|
|
|
|
|
|
|
| |
The example below should work identically with and without compiler native
wchar_t support.
void foo(wchar_t * t = L"");
Differential Revision: http://reviews.llvm.org/D19056
llvm-svn: 266287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed
needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with
backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a
problem because we would consider paths with different separators as different (which led to
unresolved breakpoints for instance).
Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I
am commenting out the GetDirectory unittests until we figure out the what is the expected
behaviour here.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19060
llvm-svn: 266286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The only difference between the removed tests and the pre-existing
ones, is the materialization of the zero constant, which shouldn't
matter for these cases.
Reviewers: dsanders, sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: http://reviews.llvm.org/D18693
llvm-svn: 266285
|
|
|
|
|
|
|
|
| |
Approved by: Justin Bogner <mail@justinbogner.com>
Differential Revision: http://reviews.llvm.org/D18756
llvm-svn: 266284
|
|
|
|
|
|
|
|
| |
The custom zone implementation for OS X must not return 0 (even for 0-sized allocations). Returning 0 indicates that the pointer doesn't belong to the zone. This can break existing applications. The underlaying allocator allocates 1 byte for 0-sized allocations anyway, so returning 1 in this case is okay.
Differential Revision: http://reviews.llvm.org/D19100
llvm-svn: 266283
|
|
|
|
|
|
|
|
| |
This reverts commit r266086.
It breaks the LTO build of gcc in SPEC2000.
llvm-svn: 266282
|
|
|
|
|
|
|
| |
only one input file
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266281
|
|
|
|
|
|
|
|
| |
vpmov{d|q}{b|w|d}{128|256|512} instruction set
Differential Revision: http://reviews.llvm.org/D19055
llvm-svn: 266280
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The behavior of {MIN,MAX}NAN differs from that of {MIN,MAX}NUM when only
one of the inputs is NaN: -NUM will return the non-NaN argument while
-NAN would return NaN.
It is desirable to lower to @llvm.{min,max}num to -NAN if they don't
have a native instruction for -NUM. Notably, ARMv7 NEON's vmin has the
-NAN semantics.
N.B. Of course, it is only safe to do this if the intrinsic call is
marked nnan.
llvm-svn: 266279
|
|
|
|
|
|
|
|
| |
vpmovus{d|q}{b|w|d}{128|256|512} instruction set
Differential Revision: http://reviews.llvm.org/D19050
llvm-svn: 266278
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266277
|
|
|
|
|
|
|
| |
Currently trying to nuke this API from LLVM.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266276
|
|
|
|
|
|
|
|
| |
This code was creating a new type in the global context, regardless
of which context the user is sitting in, what can possibly go wrong?
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266275
|
|
|
|
| |
llvm-svn: 266274
|
|
|
|
|
|
|
|
|
| |
They are unnecessary, as the dynamic loader can apply the original relocations
directly. This was also resulting in the creation of copy relocations in PIEs.
Differential Revision: http://reviews.llvm.org/D19089
llvm-svn: 266273
|
|
|
|
|
|
| |
Also add generic DAG node for it.
llvm-svn: 266272
|
|
|
|
| |
llvm-svn: 266271
|
|
|
|
| |
llvm-svn: 266270
|
|
|
|
|
|
|
| |
an offset from the current record rather than as an absolute bit number. This
gives a minor .pcm file size reduction.
llvm-svn: 266269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AllKindInfo is being indexed by NodeKindId, so the order must match.
Extended ASTTypeTraits tests to cover this.
Reviewers: sbenza
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D19059
llvm-svn: 266268
|
|
|
|
|
|
| |
which makes it print ivar and method information, as well as an optional regex argument which filters out all class names that don't match the regex
llvm-svn: 266267
|
|
|
|
|
|
|
|
| |
a table entry in the corresponding decl, store an offset from the current
record to the relevant CXX_BASE_SPECIFIERS record. This results in fewer
indirections and a minor .pcm file size reduction.
llvm-svn: 266266
|
|
|
|
|
|
| |
-fno-ms-compatibility.
llvm-svn: 266265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r265877 tries to put methods that are deprecated or unavailable to the
front of the global pool to emit diagnostics, but it breaks some of
our existing codes that depend on choosing a certain method for id
lookup.
This commit orders the methods with the same declaration with respect
to the availability, but do not order methods with different declaration.
rdar://25707511
llvm-svn: 266264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-owning pointers that cache LLVM types and constants can use
'nullptr' default member initializers so that we don't need to mention
them in the constructor initializer list.
Owning pointers should use std::unique_ptr so that we don't need to
manually delete them in the destructor. They also don't need to be
mentioned in the constructor at that point.
NFC
llvm-svn: 266263
|
|
|
|
| |
llvm-svn: 266262
|
|
|
|
| |
llvm-svn: 266261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At some point, ARM stopped getting any benefit from ConstantHoisting because
the pass called a different variant of getIntImmCost. Reimplementing the
correct variant revealed some problems, however:
+ ConstantHoisting was modifying switch statements. This is simply invalid,
the cases must remain integer constants no matter the notional cost.
+ ConstantHoisting was mangling alloca instructions in the entry block. These
should be handled by FrameLowering, so constants actually have a cost of 0.
Worse, the resulting bitcasts meant they became dynamic allocas.
rdar://25707382
llvm-svn: 266260
|
|
|
|
|
|
|
|
| |
migration away from LLVMAttribute"
This reverts commit 0bcfd95c268bcb180a525e1837e84475df8acdc7.
llvm-svn: 266259
|