| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 266197
|
|
|
|
| |
llvm-svn: 266196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
result_formatter used inspect.getfile() to get the python file name, which returned "*.pyc" if
the bytecode file was present. This resulted in files being displayed with the wrong extension,
and more critically, would confuse the rerun logic because it would try to rerun the pyc file
(which resulted in an empty rerun list as unittest refused to run those).
Fix: use inspect.getsourcefile() instead.
I am not sure why does was not an issue before. I can only assume that some system update
tricked python into producing bytecode files more aggressively.
llvm-svn: 266192
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
will not exceed the bounds of their Section. This is addressing a
problem where a file had a large space between two sections that
were not used by this module - the last symbol in the text section
had an enormous size because the distance between that and the first
symbol in the data section were used to compute the size.
http://reviews.llvm.org/D19004
<rdar://problem/25227945>
llvm-svn: 266165
|
|
|
|
| |
llvm-svn: 266164
|
|
|
|
|
|
|
|
| |
When run with the multiprocess test runner, the getchar() trick doesn't work, so ninja check-lldb would fail on this test, but running the test directly worked fine.
Differential Revision: http://reviews.llvm.org/D19035
llvm-svn: 266145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specify the demangled name. So all of the following now work:
(lldb) b ~Foo
(lldb) b Foo::~Foo
(lldb) b Bar::Foo::~Foo
Improved out C++ breakpoint locations tests as well to cover this issue.
<rdar://problem/25577252>
llvm-svn: 266139
|
|
|
|
|
|
| |
accepting them, and fail to add any strings that fail parsing
llvm-svn: 266138
|
|
|
|
|
|
| |
the real way to invoke it
llvm-svn: 266129
|
|
|
|
|
|
|
|
| |
checked in that is now reverted.
<rdar://problem/25643874>
llvm-svn: 266118
|
|
|
|
|
|
| |
This time it should also pass the gtests
llvm-svn: 266103
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The result variables aren't useful, and if you have a breakpoint on a
common function you can generate a lot of these. So I changed the
code that checks the condition to set ResultVariableIsInternal in the
EvaluateExpressionOptions that we pass to the execution.
Unfortunately, the check for this variable was done in the wrong place
(the static UserExpression::Evaluate) which is not how breakpoint
conditions execute expressions (UserExpression::Execute). So I moved
the check to UserExpression::Execute (which Evaluate also calls) and made the
overridden method DoExecute.
llvm-svn: 266093
|
|
|
|
|
|
| |
this test ever succeeded on OS X.
llvm-svn: 266092
|
|
|
|
|
|
|
| |
this test was unintentionally XFAILed due to a change in the behavior of the expectedFailure
decorator. Fix that. Also, mark the test as debug-info independent while I'm in there.
llvm-svn: 266072
|
|
|
|
|
|
|
| |
the process info packet is slow, and sometimes it does not arrive on time when run on the android
emulator.
llvm-svn: 266058
|
|
|
|
| |
llvm-svn: 266054
|
|
|
|
|
|
|
|
|
|
| |
was lost as part of the SystemLifetimeManager work"
This change breaks python unit tests.
This reverts commit 266033.
llvm-svn: 266050
|
|
|
|
|
|
|
|
| |
The structure definitions are not provided, but we perform a sizeof operation of
them which causes a build failure. Include `asm/ptrace.h` to get the structure
definitions.
llvm-svn: 266042
|
|
|
|
|
|
| |
as part of the SystemLifetimeManager work
llvm-svn: 266033
|
|
|
|
|
|
|
|
| |
*" before using it so we don't crash if a variable's type can't be realized which happens more often recently due to -gmodules.
<rdar://problem/25612626>
llvm-svn: 266023
|
|
|
|
|
|
| |
rdar://problem/24401051
llvm-svn: 266001
|
|
|
|
| |
llvm-svn: 265979
|
|
|
|
| |
llvm-svn: 265978
|
|
|
|
| |
llvm-svn: 265959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we recieve a SIGCONT or SIGTSTP, while the driver is shutting down (which, sometimes, we do,
for reasons which are not completely clear to me), we would crash to due a null pointer
dereference. Guard against this situation.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18965
llvm-svn: 265958
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18912
llvm-svn: 265948
|
|
|
|
| |
llvm-svn: 265931
|
|
|
|
| |
llvm-svn: 265921
|
|
|
|
|
|
|
| |
The makefile was explicitly setting LDFLAGS what is breaking some rules
in the global makefile.
llvm-svn: 265920
|
|
|
|
| |
llvm-svn: 265906
|
|
|
|
|
|
| |
TSan logic from SBThread to InstrumentationRuntime plugin.
llvm-svn: 265905
|
|
|
|
| |
llvm-svn: 265869
|
|
|
|
| |
llvm-svn: 265865
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thread id
-thread-info in lldbmi does not conform to protocol. Should end with
current thread id as described here:
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Thread-Commands.html#GDB_002fMI-Thread-Commands
When printing all threads, the current thread id should be printed
afterwards.
Example:
-thread-info
^done,threads=[
{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",
frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",
args=[]},state="running"},
{id="1",target-id="Thread 0xb7e156b0 (LWP 21254)",
frame={level="0",addr="0x0804891f",func="foo",
args=[{name="i",value="10"}],
file="/tmp/a.c",fullname="/tmp/a.c",line="158"},
state="running"}],
current-thread-id="1"
(gdb)
Patch from jacdavis@microsoft.com
Reviewers: zturner, chuckr
Differential Revision: http://reviews.llvm.org/differential/revision/edit/18880/
llvm-svn: 265858
|
|
|
|
|
|
| |
Fixes <rdar://problem/25629755>
llvm-svn: 265849
|
|
|
|
|
|
| |
http://reviews.llvm.org/D18886
llvm-svn: 265843
|
|
|
|
|
|
|
|
|
|
| |
This code was getting evaluated unintentionally at binding
generation time instead of binding file compilation time.
Addresses:
https://bugs.swift.org/browse/SR-1192
llvm-svn: 265829
|
|
|
|
|
|
|
|
|
| |
This triggers in some timeout scenarios in the LLDB test suite.
Fixes:
https://bugs.swift.org/browse/SR-1193
llvm-svn: 265821
|
|
|
|
|
|
| |
allow to make aliases starting with a - as that isn't really supported, and is most often a mistake (trying to pass options)
llvm-svn: 265820
|
|
|
|
| |
llvm-svn: 265819
|
|
|
|
| |
llvm-svn: 265818
|
|
|
|
|
|
|
| |
This commit touches whitespace only.
This commit was the original intention of the botched 265797
llvm-svn: 265808
|
|
|
|
| |
llvm-svn: 265799
|
|
|
|
| |
llvm-svn: 265797
|
|
|
|
| |
llvm-svn: 265787
|
|
|
|
|
|
|
|
|
|
| |
are properly escaped in Python.
The Python import works by ensuring the directory of the module or package is in sys.path, and then it does a Python `import foo`. The original code was not escaping the backslashes in the directory path, so this wasn't working.
Differential Revision: http://reviews.llvm.org/D18873
llvm-svn: 265738
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
os to "ios" or "macosx" if it is unspecified. For environments
where there genuinely is no os, we don't want to errantly
convert that to ios/macosx, e.g. bare board debugging.
Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and
PlatformRemoteAppleTV to not create themselves if we have
an unspecified OS. Same problem - these are not appropriate
platforms for bare board debugging environments.
Have Process::Attach's logging take place if either
process or target logging is enabled.
<rdar://problem/25592378>
llvm-svn: 265732
|
|
|
|
| |
llvm-svn: 265656
|
|
|
|
| |
llvm-svn: 265652
|
|
|
|
|
|
| |
printing evaluation errors for AddressSanitizer (both MemoryHistoryASan.cpp and AddressSanitizerRuntime.cpp). Hopefully this will make the ASan testcases pass or at least the failure should be easier to diagnose.
llvm-svn: 265651
|