A few fixes:
- Check the process state to make sure it is stopped
- Grab the frame from the "exe_ctx" so this will work during breakpoint callbacks
- Print out the SBDeclaration objects of the variables that shadow each other so we can see the source locations of which variable declarations are shodowing each other.
llvm-svn: 273963
the new pass manager.
This adds operator<< overloads for the various bits of the
LazyCallGraph, dump methods for use from the debugger, and debug logging
using them to the CGSCC pass manager.
Having this was essential for debugging the call graph update patch, and
I've extracted what I could from that patch here to minimize the delta.
llvm-svn: 273961
Target::Install() was assuming the module at index 0 was the executable.
This is often true, but not guaranteed to be the case. The
TestInferiorChanged.py test highlighted this when run against iOS.
After the binary is replaced in the middle of the test, it becomes the
last module in the list. The rest of the Target::Install() logic then
clobbers the executable file by using whatever happens to be the first
module in the target module list.
This change also marks the TestInferiorChanged.py test as a no-debug-info
test.
llvm-svn: 273960
Apparently, MSVC complains if there's an implicit conversion from
`unsigned` to `unsigned long long`, if the `unsigned` is the result of
a bit shift.
llvm-svn: 273955
explicit in how it adds the kernel binary, to guard against the
case where a kernel corefile might incorrectly include the kernel's
UUID in it (so calling ::GetSharedModule may end up returning the
global module cache's copy of the core file instead of adding the
kerenl binary).
<rdar://problem/26988816>
llvm-svn: 273954
allow a good error message to be produced.
I added the one test case that the object file tools could produce an error
message. The other two errors can’t be triggered if the input file is passed
through sys::fs::identify_magic(). But the malformedError("bad magic number")
does get triggered by the logic in llvm-dsymutil when dealing with a normal
Mach-O file. The other "File too small ..." error would take a logic error
currently to produce and is not tested for.
llvm-svn: 273946
As it failed on e.g.
<http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/7089/steps/ninja%20check%201/logs/FAIL%3A%20Clang%20Tools%3A%3AClassTestReplacements.cpp> with:
Trouble iterating over directory '/home/buildbots/ppc64be-clang-test/clang-ppc64be/stage1/tools/clang/tools/extra/test/clang-rename/Output': No such file or directory
A reliable way to trigger the problem locally is to run all clang-rename
tests in parallel in a loop:
for i in $(seq 1 100); do ~/git/llvm/workdir/bin/llvm-lit -v -j15 . || break; done
Change the test script to be more similar to test/Tooling/clang-check.cpp, that
way the above command doesn't fail for me anymore.
llvm-svn: 273941
binutils ar uses -plugin to specify the LTO plugin, but LLVM doesn't
need this as it doesn't use a plugin for LTO. Accepting (and ignoring)
the option allows interoperability with existing build systems and
make downstream consumers life much easier.
No objections from Rafael on this change.
llvm-svn: 273938
Summary:
Our YAML library's handling of tags isn't perfect, but it is good enough to get rid of the need for the --format argument to yaml2obj. This patch does exactly that.
Instead of requiring --format, it infers the format based on the tags found in the object file. The supported tags are:
!ELF
!COFF
!mach-o
!fat-mach-o
I have a corresponding patch that is quite large that fixes up all the in-tree test cases.
Reviewers: rafael, Bigcheese, compnerd, silvas
Subscribers: compnerd, llvm-commits
Differential Revision: http://reviews.llvm.org/D21711
llvm-svn: 273915
The triple must be parsed in base-config-ix.cmake.
Otherwise, the cmake variable ANDROID won't be set and this
will confuse cmake to build unsupported targets targeted for
android.
Diferential revision: http://reviews.llvm.org/D21474
llvm-svn: 273914
This fixes a crash in code like:
```
struct A {
struct B b;
char c[1];
}
int foo(struct A* a) { return __builtin_object_size(a->c, 0); }
```
We wouldn't check whether the structs we were examining were invalid,
and getting the layout of an invalid struct is (unsurprisingly) A Bad
Thing. With this patch, we'll always return conservatively if we see an
invalid struct, since I'm assuming the presence of an invalid struct
means that our compilation failed (so having a conservative result isn't
such a big deal).
llvm-svn: 273911
Use case: a class is declared in a header, and defined in two
translation units. clang-rename is asked to rename a class member that's
referenced in both translation units.
Using -i is not possible, as in case the first clang-rename invocation
touches the header, the second invocation will result in compilation
errors. Using -export-fixes handles this situation, each invocation can
work on the original source, and at the end the user can apply the
replacements with clang-apply-replacements.
Reviewers: klimek
Differential Revision: http://reviews.llvm.org/D21676
llvm-svn: 273910
Reject and report regions that contains loops overlapping nonaffine region.
This situation typically happens in the presence of inifinite loops.
This addresses bug llvm.org/PR28071.
Differential Revision: http://reviews.llvm.org/D21312
Contributed-by: Huihui Zhang <huihuiz@codeaurora.org>
llvm-svn: 273905
Matt Arsenault