The ELF writer creates a invalid binary for few cases with large filesize and
memory size for segments. This patch addresses the functionality and updates the
test. This patch also cleans up parts of the ELF writer for future enhancements
to support Linker scripts.
llvm-svn: 221233
is "invalid" -- it is past the end of the stack trace. Add a new
method IsCompletedStackWalk() so we can tell if an invalid stack
frame is from a complete backtrace or if it might be worth re-trying
the last unwind with a different method.
This fixes the unwinder problems Ryan Brown was having with go
programs. The unwinder can (under the right circumstances) still
destructively replace unwind plans permanently - I'll work on
that in a different patch.
<rdar://problem/18683658>
llvm-svn: 221229
This commit changes the place where TSan runtime turns full path
to binary or shared library into its basename
(/usr/foo/mybinary -> mybinary). Instead of doing it as early as possible
(when we obtained the full path from the symbolizer), we now do it as
late as possible (right before printing the error report).
This seems like a right thing to do - stripping to basename is a detail
of report formatting implementation, and should belong there. Also, we
might need the full path at some point - for example, to match the
suppressions.
llvm-svn: 221225
preserve LoopSimplify because instcombine may replace branch predicates
with undef which loop simplify then replaces with always exit. Replace
setPreservesCFG with the more constrained preservation of DomTree and
LoopInfo.
llvm-svn: 221223
We shouldn't put this kind of attribute stuff in DataTypes.h.
Leave the END_WITH_NULL name for now so I can update clang without
making build spam.
llvm-svn: 221215
The problem was that SBTarget::ReadMemory() was making a new section offset lldb_private::Address by doing:
size_t
SBTarget::ReadMemory (const SBAddress addr,
void *buf,
size_t size,
lldb::SBError &error)
{
...
lldb_private::Address addr_priv(addr.GetFileAddress(), NULL);
bytes_read = target_sp->ReadMemory(addr_priv, false, buf, size, err_priv);
This is wrong. If you get the file addresss from the "addr" argument and try to read memory using that, it will think the file address is a load address and it will try to resolve it accordingly. This will work fine if your executable is loaded at the same address (no slide), but it won't work if there is a slide.
The fix is to just pass along the "addr.ref()" instead of making a new addr_priv as this will pass along the lldb_private::Address that is inside the SBAddress (which is what we want), and not always change it into something that becomes a load address (if we are running), or abmigious file address (think address zero when you have 150 shared libraries that have sections that start at zero, which one would you pick). The main reason for passing a section offset address to SBTarget::ReadMemory() is so you _can_ read from the actual section + offset that is specified in the SBAddress.
llvm-svn: 221213
Normally, PE files have section names of eight characters or less.
However, this is problematic for DWARF because DWARF section names are
things like .debug_aranges.
Instead of truncating the section name, redirect the section name into
the string table.
Differential Revision: http://reviews.llvm.org/D6104
llvm-svn: 221212
Objective-C runtime. We'll need to do more
(subclasses, partially-defined classes, etc.)
but this tests that at least the basics work.
llvm-svn: 221208
When processes are launched for debugging on Windows now, LLDB
will detect changes such as DLL loads and unloads, breakpoints,
thread creation and deletion, etc.
These notifications are not yet propagated to LLDB in a way that
LLDB understands what is happening with the process. This only
picks up the notifications from the OS in a way that they can be
sent to LLDB with subsequent patches.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6037
llvm-svn: 221207
mingw64's headers implement fabs by calling __builtin_fabs, so using the
library call results in an infinite loop. If the backend legalizes
@llvm.fabs as a call to fabs later, things should work out, as the crt
provides a definition.
llvm-svn: 221206
LoadCombine can be smarter about aborting when a writing instruction is
encountered, instead of aborting upon encountering any writing instruction, use
an AliasSetTracker, and only abort when encountering some write that might
alias with the loads that could potentially be combined.
This was originally motivated by comments made (and a test case provided) by
David Majnemer in response to PR21448. It turned out that LoadCombine was not
responsible for that PR, but LoadCombine should also be improved so that
unrelated stores (and @llvm.assume) don't interrupt load combining.
llvm-svn: 221203
This generalizes the range handling for ranges in both the skeleton and
full unit, laying the foundation for the addition of more ranges (rather
than just the CU's special case) in the skeleton CU with fission+gmlt.
llvm-svn: 221202
Summary:
This change removes `__tsan::StackTrace` class. There are
now three alternatives:
# Lightweight `__sanitizer::StackTrace`, which doesn't own a buffer
of PCs. It is used in functions that need stack traces in read-only
mode, and helps to prevent unnecessary allocations/copies (e.g.
for StackTraces fetched from StackDepot).
# `__sanitizer::BufferedStackTrace`, which stores buffer of PCs in
a constant array. It is used in TraceHeader (non-Go version)
# `__tsan::VarSizeStackTrace`, which owns buffer of PCs, dynamically
allocated via TSan internal allocator.
Test Plan: compiler-rt test suite
Reviewers: dvyukov, kcc
Reviewed By: kcc
Subscribers: llvm-commits, kcc
Differential Revision: http://reviews.llvm.org/D6004
llvm-svn: 221194
This reverts commit r221159, as clang-format is again back to its old behaviour
and we do not cause any buildbot error messages any more.
llvm-svn: 221189
Now we don't warn on this code:
void __stdcall f(void);
void __stdcall f();
My previous commit regressed this functionality because I didn't update
the relevant test case which used a definition.
llvm-svn: 221188
FoldOpIntoPhi could create an infinite loop if the PHI could potentially
reach a BB it was considering inserting instructions into. The
instructions it would insert would eventually lead to other combines
firing which would, again, lead to FoldOpIntoPhi firing.
The solution is to handicap FoldOpIntoPhi so that it doesn't attempt to
insert instructions that the PHI might reach.
This fixes PR21377.
llvm-svn: 221187
So that it may be shared between skeleton/full compile unit, for CU
ranges and other ranges to be added for fission+gmlt.
(at some point we might want some kind of object shared between the
skeleton and full compile units for all those things we only want one of
in that scope, rather than having the full unit always look through to
the skeleton... - alternatively, we might be able to have the skeleton
pointer (or another, separate pointer) point to the skeleton or to the
unit itself in non-fission, so we don't have to special case its
absence)
llvm-svn: 221186
Eric Fiselier