| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Even after the last fixup, there still seems to be one failure left. Revert until I figure out
what is going on.
llvm-svn: 262622
|
|
|
|
| |
llvm-svn: 262602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
this enables download of remote log files for llgs and debugserver tests (previously we were just
passing the host file name which obviously did not work). Note this also changes the debugserver
logging to work only when logging has been requested on the command line, whereas previously it
would log unconditionally. I can change it back if anyone is relying on this, but I thought I'd
make this consistent.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17798
llvm-svn: 262597
|
|
|
|
|
|
| |
we're sometimes getting an exception here, and I want to see why...
llvm-svn: 262333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
points the user to the apropos and type lookup commands
This is useful in cases such as, e.g.
(lldb) help NSString
(the user meant type lookup)
or
(lldb) help kill
(the user is looking for process kill)
Fixes rdar://24868537
llvm-svn: 262271
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inlining semantics for C and C++ are different, which affects the test's expectation of the number of times the function should appear in the binary. In the case of this test, C semantics means there should be three instances of inner_inline, while C++ semantics means there should be only two.
On Windows, clang uses C++ inline semantics even for C code, and there doesn't seem to be a combination of compiler flags to avoid this.
So, for consistency, I've recast the test to use C++ everywhere. Since the test resided under lang/c, it seemed appropriate to move it to lang/cpp.
This does not address the other XFAIL for this test on Linux/gcc. See https://llvm.org/bugs/show_bug.cgi?id=26710
Differential Revision: http://reviews.llvm.org/D17650
llvm-svn: 262255
|
|
|
|
|
|
|
|
|
|
|
|
| |
SysV ARM (hard/soft) ABI."
This partially reverts commit r262218.
The commit added additional checks to a test case. The test case is too big so it's not feasible
to XFAIL it completely. Suggest to implement the checks as a separate test case, which can then
be XFAILed more surgically.
llvm-svn: 262223
|
|
|
|
|
|
|
|
|
|
| |
(hard/soft) ABI.
For details see:
Differential revision: http://reviews.llvm.org/D17708
llvm-svn: 262218
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary: The debug version of libc.so is require for backtracing which may not be available on all platforms.
Reviewers: ovyalov, clayborg
Subscribers: zturner, lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: http://reviews.llvm.org/D17131
llvm-svn: 262011
|
|
|
|
| |
llvm-svn: 261974
|
|
|
|
|
|
|
|
|
| |
"sif <target function>" - i.e. step-into-function
to allow you to step through a complex calling sequence into a particular function that may span multiple lines. Also some
test cases for this and the --step-target feature.
llvm-svn: 261953
|
|
|
|
|
|
|
|
| |
Test expects the breakpoint to resolve to three locations, but clang on windows yields only 2.
llvm.org/pr26710
llvm-svn: 261810
|
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit processes on 64-bit Windows run in a layer called WoW64 (Windows-on-Windows64). If you capture a mini dump of such a process from a 32-bit debugger, you end up with a register context for the 64-bit WoW64 process rather than the 32-bit one you probably care about.
This detects WoW64 by looking to see if there's a module named wow64.dll loaded. For such processes, it then looks in the 64-bit Thread Environment Block (TEB) to locate a copy of the 32-bit CONTEXT record that the plugin needs for the register context.
Added some rudimentary tests. I'd like to improve these later once we figure out how to get the exception information from these mini dumps.
Differential Revision: http://reviews.llvm.org/D17465
llvm-svn: 261808
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two tests in this file. One which only runs on Windows
and tests that you can set a breakpoint with mismatched case. And
another that only runs on non-Windows and tests that you cannot set
a breakpoint with mismatched case. This latter test is failing on
non Windows platforms for some reason. It could be that the test
is just written incorrectly, as I think the actual functionality
actually works correctly on non-Windows platforms.
llvm-svn: 261800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Paths on Windows are not case-sensitive. Because of this, if a file
is called main.cpp, you should be able to set a breakpoint on it
by using the name Main.cpp. In an ideal world, you could just
tell people to match the case, but in practice this can be a real
problem as it requires you to know whether the person who compiled
the program ran "clang++ main.cpp" or "clang++ Main.cpp", both of
which would work, regardless of what the file was actually called.
This fixes http://llvm.org/pr22667
Patch by Petr Hons
Differential Revision: http://reviews.llvm.org/D17492
Reviewed by: zturner
llvm-svn: 261771
|
|
|
|
| |
llvm-svn: 261630
|
|
|
|
| |
llvm-svn: 261599
|
|
|
|
|
|
|
| |
Test has become flaky again. Attempts to investigate the triggering commit have failed, so I
suspect it was flaky all along..
llvm-svn: 261519
|
|
|
|
|
|
|
|
| |
All invocations are updated to use the generic expectedFailureAll.
Differential Revision: http://reviews.llvm.org/D17455
llvm-svn: 261355
|
|
|
|
|
|
|
|
|
|
|
| |
There is a report in the PR from several months ago that it failed
intermittently, but it is passing consistently for me on FreeBSD 10
and 11. We can re-add a decorator if further testing shows it is
still flakey.
llvm.org/pr17214
llvm-svn: 261340
|
|
|
|
|
|
|
|
| |
This is passing for me consistently on FreeBSD 10 and FreeBSD 11.
llvm.org/pr15989
llvm-svn: 261339
|
|
|
|
|
|
|
|
| |
Both Linux and FreeBSD had a comment "This needs to be root-caused."
It looks like the failure has been fixed on both, and the Linux XFAIL
decorator was removed in r233716 (Mar 2015).
llvm-svn: 261333
|
|
|
|
|
|
| |
Test should work everywhere except windows now.
llvm-svn: 261314
|
|
|
|
|
|
|
|
| |
flaky on linux
The problem is the asynchronous arrival of inferior stdio (pr25652).
llvm-svn: 261313
|
|
|
|
|
|
|
|
|
| |
on attach uses the architecture it has figured out, rather than the Target's
architecture, which may not have been updated to the correct value yet.
<rdar://problem/24632895>
llvm-svn: 261279
|
|
|
|
|
|
|
|
|
| |
The race condition/use after free involved in setting long prompts
appears to be fixed now (although I do not know which commit fixed it).
llvm.org/pr22611
llvm-svn: 261266
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17088
llvm-svn: 261241
|
|
|
|
|
|
|
| |
The test fails very rarely. I suspect this is simply because the inferior does not have enough
time to create the file under heavy load.
llvm-svn: 260951
|
|
|
|
|
|
|
|
| |
on linux
I believe the root cause is the asynchronous arrival of inferior stdio (pr25652).
llvm-svn: 260950
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is the form on other libc++ tests.
Reviewers: sivachandra
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17230
llvm-svn: 260793
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17227
llvm-svn: 260770
|
|
|
|
|
|
|
|
|
|
| |
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"
All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable
Fixes rdar://24329405
llvm-svn: 260752
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This does not yet give us a clean testsuite run but it does help with:
1. Actually building on linux
2. Run the testsuite with over 70% tests passing on linux.
Reviewers: tfiala, labath, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17182
llvm-svn: 260721
|
|
|
|
|
|
|
| |
Test cases should not be named after PR or Radar numbers. It's fine to
annotate them with these numbers in comments, however.
llvm-svn: 260699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
contain logic to inspect the objects without running code.
However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects.
The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information.
Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users.
As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes.
This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters.
While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit.
llvm-svn: 260664
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clearing the map ended up calling back into the TypeSystemMap to do lookups.
Not a good idea, and in this case it would cause a deadlock.
You would only see this when replacing the target contents after an exec, and only if you
had stopped before the exec, evaluated an expression, then continued
on to the point where you did the exec.
Fixed this by making sure the TypeSystemMap::Clear tears down the TypeSystems in the map before clearing the map.
I also add an expression before exec to the TestExec.py so that we'll catch this
issue if it crops up again in the future.
<rdar://problem/24554920>
llvm-svn: 260624
|
|
|
|
| |
llvm-svn: 260589
|
|
|
|
| |
llvm-svn: 260440
|
|
|
|
|
|
|
| |
This was supposed to have been removed but made it back in
accidentally.
llvm-svn: 260423
|
|
|
|
| |
llvm-svn: 260422
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Reviewers: clayborg, jaydeep.
Subscribers: zturner, bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D16840
llvm-svn: 260362
|
|
|
|
|
|
|
|
|
|
| |
the value being cast to return a Python number with the proper value
The explicit APIs on SBValue obviously remain if one wants to be explicit in intent, or override this guess, but since __int__() has to pick one, an educated guess is definitely better than than always going to signed regardless
Fixes rdar://24556976
llvm-svn: 260349
|
|
|
|
|
|
|
|
|
|
| |
CFLAGS is now being set correctly to pass -flimit-debug-info or
-fno-limit-debug-info on FreeBSD. I'm not sure which change is
responsible for the fix, though.
llvm.org/pr25626
llvm-svn: 260330
|
|
|
|
| |
llvm-svn: 260292
|
|
|
|
|
|
|
| |
These were supposed to have been removed in a previous patch,
but I missed them.
llvm-svn: 260291
|
|
|
|
|
|
| |
All existing usages were ported over to the common decorators.
llvm-svn: 260290
|
|
|
|
|
|
| |
Ported everything over to using expectedFailureAll.
llvm-svn: 260289
|
|
|
|
|
|
|
| |
All decorator invocations are updated to use the generic
expectedFailureAll and skipIf decorators.
llvm-svn: 260288
|
|
|
|
| |
llvm-svn: 260216
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17014
llvm-svn: 260192
|