| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 257152
|
| |
|
|
| |
llvm-svn: 257151
|
| |
|
|
| |
llvm-svn: 257150
|
| |
|
|
|
|
| |
mistake I made years ago.
llvm-svn: 257149
|
| |
|
|
|
|
| |
consistency.
llvm-svn: 257148
|
| |
|
|
| |
llvm-svn: 257147
|
| |
|
|
| |
llvm-svn: 257146
|
| |
|
|
|
|
|
|
|
| |
Done in InstrProfWriter to eliminate the need for client
code to do the sorting. The operation is done once and reused
many times so it is more efficient. Update unit test to remove
sorting. Also update expected output of affected tests.
llvm-svn: 257145
|
| |
|
|
| |
llvm-svn: 257144
|
| |
|
|
|
|
|
|
|
|
| |
For a new record with weight != 1, only edge profiling
counters are scaled, VP data is not properly scaled.
This patch refactors the code and fixes the problem.
Also added sort by count interface (for follow up patch).
llvm-svn: 257143
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Trying to make this test a bit more manageable.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15974
llvm-svn: 257142
|
| |
|
|
|
|
| |
SIZE relocations are not PC-relative, so isRelRelative should return false.
llvm-svn: 257141
|
| |
|
|
| |
llvm-svn: 257140
|
| |
|
|
|
|
|
|
|
| |
This remove the need for locking when deleting a function.
Differential Revision: http://reviews.llvm.org/D15988
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 257139
|
| |
|
|
|
|
|
|
| |
puts a breakpoint" it is causing a regression in the TestStepNoDebug
test case on ubuntu 14.04 with gcc 4.9.2. Thanks for the email
Siva. I'll recommit when I've figured out the regression.
llvm-svn: 257138
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix for bug http://llvm.org/bugs/show_bug.cgi?id=25839.
For a PIC TLS variable access in a function, prologue (mflr followed by std and
stdu) gets scheduled after a tls_get_addr call. tls_get_addr messed up LR but
no one saves/restores it.
Also added a test for save/restore clobbered registers during calling __tls_get_addr.
Patch by Tim Shen
llvm-svn: 257137
|
| |
|
|
|
|
| |
Unbreaks clang-cl build (cl warns on this flag, clang-cl errors on it).
llvm-svn: 257136
|
| |
|
|
|
|
|
|
|
|
|
| |
Add long long/double support for vec_cts, vec_ctu and vec_ctf.
Similar to this change in GCC:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02653.html
Patch by Tim Shen.
llvm-svn: 257135
|
| |
|
|
|
|
|
|
|
|
| |
The early return seems to be missed. This causes a radical and wrong loop
optimization on powerpc. It isn't reproducible on x86_64, because
"UseInterleaved" is false.
Patch by Tim Shen.
llvm-svn: 257134
|
| |
|
|
|
|
|
|
| |
Limit this transform to a basic block and guard against PHIs.
Hopefully, this fixes the remaining failures in PR25999:
https://llvm.org/bugs/show_bug.cgi?id=25999
llvm-svn: 257133
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If two dwarf sequences begin with entries that have identical addresses,
it is possible for the comparator to order the first entry of the new
sequence between the first and second entries of the existing sequence.
This will result in an attempted insertion of the second sequence inside
of the first sequence, which is invalid.
Ensure that insertions only occur in between existing sequences.
Reviewers: andrew.w.kaylor, clayborg
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D15979
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257132
|
| |
|
|
| |
llvm-svn: 257131
|
| |
|
|
|
|
|
|
| |
The new leader is known anyway so we can return it for some micro
optimization in code where it is easy to pass along the result to the
next join().
llvm-svn: 257130
|
| |
|
|
| |
llvm-svn: 257129
|
| |
|
|
| |
llvm-svn: 257128
|
| |
|
|
|
|
|
| |
WebAssemblyISelLowering.cpp does not wrap jump table nodes inside of
WebAssemblywrapper nodes, so this pattern is not currently used.
llvm-svn: 257127
|
| |
|
|
| |
llvm-svn: 257126
|
| |
|
|
| |
llvm-svn: 257125
|
| |
|
|
| |
llvm-svn: 257124
|
| |
|
|
| |
llvm-svn: 257123
|
| |
|
|
|
|
|
|
| |
and fix a couple of bugs on inspection.
Also fixes PR26061.
llvm-svn: 257122
|
| |
|
|
|
|
|
|
|
| |
"qserial" to "qserialnum" because "qserial" looks a lot like the
queue type (either 'serial' or 'concurrent') and can be confusing
to read through. debugserver passes these up either in the questionmark
("T") packet, or in the response to the jThreadsInfo packet.
llvm-svn: 257121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Batch mode is supposed to stop execution and return control to the user when an
exceptional stop occurs (crash, signal or instrumentation). But attach always stops
with a SIGSTOP on OSX (maybe on Linux too?) which would short circuit the rest of the
commands given.
This change allows a command result object to indicate that it expected to leave the
process stopped with an exceptional stop reason, and it is okay for batch mode to keep going.
<rdar://problem/22243143>
llvm-svn: 257120
|
| |
|
|
|
|
|
|
| |
All non-trivial relocation decisions need explanations like this
to help readers understand not only how relocations are handled but
why they are handled these ways. This is a start.
llvm-svn: 257119
|
| |
|
|
| |
llvm-svn: 257118
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on the first branch instruction after a function return (or the end
of a source line), instead of a breakpoint on the return address,
to skip an extra stop & start of the inferior process.
I changed Process::AdvanceAddressToNextBranchInstruction to not
take an optional InstructionList argument - no callers are providing
a cached InstructionList today, and if this function was going to
do that, the right thing to do would be to fill out / use a
DisassemblerSP which is a disassembler with the InstructionList for
this address range.
http://reviews.llvm.org/D15708
<rdar://problem/23309838>
llvm-svn: 257117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some debug servers don't support it so there's no point in spamming
this.
Reviewers: clayborg
Subscribers: fjricci, lldb-commits
Differential Revision: http://reviews.llvm.org/D15972
llvm-svn: 257116
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15876
llvm-svn: 257115
|
| |
|
|
| |
llvm-svn: 257114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change is relevant for inferiors compiled with GCC. GCC does not
emit complete debug info for std::basic_string<...>, and consequently, Clang
(the LLDB compiler) does not generate correct mangled names for certain
functions.
This change removes the hard-coded alternate names in
ItaniumABILanguageRuntime.cpp.
Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could
not evaluate std::string methods (ex. std::string::length). After putting in
the hard-coded names, one could evaluate them. However, it did not still
enable one to call methods on, say for example, std::vector<string>.
This change makes that possible.
There is some amount of incompleteness in this change. Consider the
following example:
std::string hello("hello"), world("world");
std::map<std::string, std::string> m;
m[hello] = world;
One can still not evaluate the expression "m[hello]" in LLDB. Will
address this issue in another pass.
Reviewers: jingham, vharron, evgeny777, spyffe, dawn
Subscribers: clayborg, dawn, lldb-commits
Differential Revision: http://reviews.llvm.org/D12809
llvm-svn: 257113
|
| |
|
|
|
|
|
| |
While adding instructions(possible roots) to be redone, make sure they
are from the same basic block.
llvm-svn: 257112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.zero is confusing when used with two arguments. Documentation:
This directive emits SIZE 0-valued bytes. SIZE must be an absolute
expression. This directive is actually an alias for the '.skip'
directive so in can take an optional second argument of the value to
store in the bytes instead of zero. Using '.zero' in this way would be
confusing however.
Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=18353
Hexagon and Sparc do the same, and it's all the same to WebAssembly so
let's pick the less confusing of the two.
llvm-svn: 257111
|
| |
|
|
|
|
|
|
|
| |
llvmBufferWriter and a few related symbols were missing from libclang_rt
on Darwin (PR26002). This should fix the problem.
Patch by Dan Peebles!
llvm-svn: 257110
|
| |
|
|
| |
llvm-svn: 257109
|
| |
|
|
|
|
| |
Move common defs into common header files.
llvm-svn: 257108
|
| |
|
|
|
|
|
| |
Looks like there's a case where clang generates debug info that triggers
the new verifier check. Reverting while investigating.
llvm-svn: 257107
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In rL255491, the safestack overflow test was disabled for aarch64, since
it "is currently failing on an AArch64 buildbot with a segfault, but it
is currently passing on other configuration".
While testing on FreeBSD on x86, I also encountered a segfault. This is
because the `fct()` function actually writes before and after `buffer`,
and on FreeBSD this crashes because `buffer` is usually allocated at the
end of a page. That this runs correctly on Linux is probably just by
accident.
I propose to fix this by adding a pre and post buffer, to act as a
safety zone. The pre and post buffers must be accessed in an 'unsafe'
way, otherwise -fsanitize=safestack will allocate them on the safe
stack, and they will not bookend `buffer` itself. Therefore, I create
them large enough for `fct()`, and call it on both of them.
On FreeBSD, this makes the test run as expected, without segfaulting,
and I suppose this will also fix the segfault on AArch64. I do not have
AArch64 testing capabilities, so if someone could try that out, I would
be much obliged.
Reviewers: pcc, kcc, zatrazz
Subscribers: llvm-commits, aemerson, emaste
Differential Revision: http://reviews.llvm.org/D15725
llvm-svn: 257106
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Teach the Verifier to make sure that the storage size given to llvm.dbg.declare
or the value size given to llvm.dbg.value agree with what is declared in
DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA).
Additionally this catches a number of common mistakes, such as passing a
pointer when a value was intended or vice versa.
One complication comes from stack coloring which modifies the original IR when
it merges allocas in order to make sure that if AA falls back to the IR it gets
the correct result. However, given this new invariant, indiscriminately
replacing one alloca by a different (differently sized one) is no longer valid.
Fix this by just undefing out any use of the alloca in a dbg.declare in this
case.
Additionally, I had to fix a number of test cases. Of particular note:
- I regenerated dbg-changes-codegen-branch-folding.ll from the given source as
it was affected by the bug fixed in r256077
- two-cus-from-same-file.ll was changed to avoid having a variable-typed debug
variable as that would depend on the target, even though this test is
supposed to be generic
- I had to manually declared size/align for reference type. See also the
discussion for D14275/r253186.
- fpstack-debuginstr-kill.ll required changing `double` to `long double`
- most others were just a question of adding OP_deref
Reviewers: aprantl
Differential Revision: http://reviews.llvm.org/D14276
llvm-svn: 257105
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the clang part of D15966. In rL256104, debugger tuning was
added to the clang driver, and again the default for FreeBSD was set to
lldb. The default needs to be gdb instead.
Reviewers: emaste, probinson
Subscribers: cfe-commits, emaste
Differential Revision: http://reviews.llvm.org/D15967
llvm-svn: 257104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In rL242338, debugger tuning was introduced, and the tuning for FreeBSD
was set to lldb by default. However, for the foreseeable future we
still need to default to gdb tuning, since lldb is not ready for all of
FreeBSD's architectures, and some system tools (like objcopy, etc) have
not yet been adapted to cope with the lldb tuned format, which has
.apple sections.
Therefore, let FreeBSD use gdb by default for now.
Reviewers: emaste, probinson
Subscribers: llvm-commits, emaste
Differential Revision: http://reviews.llvm.org/D15966
llvm-svn: 257103
|