| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
functions from being added to class definitions (see revision 260308 for details).
<rdar://problem/24483905>
<rdar://problem/24508374>
llvm-svn: 260322
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
up when parsing expressions.
1) Turns out we weren't correctly uniquing types for C++. We would search our repository for "lldb_private::Process", but yet store just "Process" in the unique type map. Now we store things correctly and correctly unique types.
2) SymbolFileDWARF::CompleteType() can be called at any time in order to complete a C++ or Objective C class. All public inquiries into the SymbolFile go through SymbolVendor, and SymbolVendor correctly takes the module lock before it call the SymbolFile API call, but when we let CompilerType objects out in the wild, they can complete themselves at any time from the expression parser, so the ValueObjects or (SBValue objects in the public API), and many more places. So we now take the module lock when completing a type to avoid two threads being in the SymbolFileDWARF at the same time.
3) If a class has a template member function like:
class A
{
<template T>
void Foo(T t);
};
The DWARF will _only_ contain a DW_TAG_subprogram for "Foo" if anyone specialized it. This would cause a class definition for A inside a.cpp that used a "int" and "float" overload to look like:
class A
{
void Foo(int t);
void Foo(double t);
};
And a version from b.cpp that used a "float" overload to look like:
class A
{
void Foo(float t);
};
And a version from c.cpp that use no overloads to look like:
class A
{
};
Then in an expression if you have two variables, one name "a" from a.cpp in liba.dylib, and one named "b" from b.cpp in libb.dylib, you will get conflicting definitions for "A" and your expression will fail. This all stems from the fact that DWARF _only_ emits template specializations, not generic definitions, and they are only emitted if they are used. There are two solutions to this:
a) When ever you run into ANY class, you must say "just because this class doesn't have templatized member functions, it doesn't mean that any other instances might not have any, so when ever I run into ANY class, I must parse all compile units and parse all instances of class "A" just in case it has member functions that are templatized.". That is really bad because it means you always pull in ALL DWARF that contains most likely exact duplicate definitions of the class "A" and you bloat the memory that the SymbolFileDWARF plug-in uses in LLDB (since you pull in all DIEs from all compile units that contain a "A" definition) uses for little value most of the time.
b) Modify DWARF to emit generic template member function definitions so that you know from looking at any instance of class "A" wether it has template member functions or not. In order to do this, we would have to have the ability to correctly parse a member function template, but there is a compiler bug:
<rdar://problem/24515533> [PR 26553] C++ Debug info should reference DW_TAG_template_type_parameter
This bugs means that not all of the info needed to correctly make a template member function is in the DWARF. The main source of the problem is if we have DWARF for a template instantiation for "int" like: "void A::Foo<int>(T)" the DWARF comes out as "void A::Foo<int>(int)" (it doesn't mention type "T", it resolves the type to the specialized type to "int"). But if you actually have your function defined as "<template T> void Foo(int t)" and you only use T for local variables inside the function call, we can't correctly make the function prototype up in the clang::ASTContext.
So the best we can do for now we just omit all member functions that are templatized from the class definition so that "A" never has any template member functions. This means all defintions of "A" look like:
class A
{
};
And our expressions will work. You won't be able to call template member fucntions in expressions (not a regression, we weren't able to do this before) and if you are stopped in a templatized member function, we won't know that are are in a method of class "A". All things we should fix, but we need <rdar://problem/24515533> fixed first, followed by:
<rdar://problem/24515624> Classes should always include a template subprogram definition, even when no template member functions are used
before we can do anything about it in LLDB.
This bug mainly fixed the following Apple radar:
<rdar://problem/24483905>
llvm-svn: 260308
|
| |
|
|
|
|
| |
CompilerType and in clang::QualType knows how to complete a type if it needs to.
llvm-svn: 260299
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
debugserver, for use with /usr/lib/libgmalloc.dylib, then make sure we don't pass this environment variable on to any child processes.
llvm-svn: 260284
|
| |
|
|
|
|
| |
was put in back in 2011 when -flimit-debug-info did a lot less than it does now. With llvm-dsymutil doing ODR type unique stuff we still have reasonably sized dSYM files.
llvm-svn: 260282
|
| |
|
|
| |
llvm-svn: 260247
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= ().
Reviewers: sagar, tberghammer, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16868
Patch by Marianne Mailhot-Sarrasin
llvm-svn: 260239
|
| |
|
|
| |
llvm-svn: 260216
|
| |
|
|
|
|
|
|
|
|
|
|
| |
causes LLDB to crash
This is because PyThreadState_Get() assumes a non-NULL thread state and crashes otherwise; but PyThreadState_GET is just a shortcut (in non-Python-debugging builds) for the global variable that holds the thread state
The behavior of CTRL+C is slightly more erratic than one would like. CTRL+C in the middle of execution of Python code will cause that execution to be interrupted (e.g. time.sleep(1000)), but a CTRL+C at the prompt will just cause a KeyboardInterrupt and not exit the interpreter - worse, it will only trigger the exception once one presses ENTER.
None of this is optimal, of course, but I don't have a lot of time to appease the Python deities with the proper spells right now, and fixing the crasher is already a good thing in and of itself
llvm-svn: 260199
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17014
llvm-svn: 260192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the following decorators:
* skipIfI386
* expectedFailureI386
* expectedFailurex86_64
* skipIfArch
* skipUnlessArch
* skipUnlessI386
And other related decorators. All code using those decorators
is updated to use expectedFailureAll and skipIf
llvm-svn: 260178
|
| |
|
|
| |
llvm-svn: 260177
|
| |
|
|
|
|
| |
Convert everything over to using skipIf.
llvm-svn: 260176
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Change the `not_in` function to be called `no_match`. This makes
it clear that keyword arguments can be more than just lists.
* Change the name of `_check_list_or_lambda` to
`_match_decorator_property`. Again clarifying that decorator params
are not always lists.
* Always use a regex match when matching strings. This allows automatic
support for regex matching on all decorator properties. Also support
compiled regex values.
* Fix a bug in the compiler check used by _decorateTest. The two
arguments were reversed, the condition was always wrong.
* Change one test that uses skipUnlessArch to use skipIf, to
demonstrate that skipIf can now handle more scenarios.
Differential Revision: http://reviews.llvm.org/D16938
llvm-svn: 260135
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expectedFailureWindows is equivalent to using the general
expectedFailureAll decorator with oslist="windows". Additionally,
by moving towards these common decorators we can solve the issue
of having to support decorators that can be called with or without
arguments. Once all decorators are always called with arguments,
and this is enforced by design (because you can't specify the condition
you're decorating for without passing an argument) the implementation
of the decorators can become much simpler
Differential Revision: http://reviews.llvm.org/D16936
llvm-svn: 260134
|
| |
|
|
| |
llvm-svn: 260082
|
| |
|
|
|
|
| |
Test is still flaky.
llvm-svn: 260081
|
| |
|
|
| |
llvm-svn: 260078
|
| |
|
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
This patch fixes TestExpressionInSyscall.py and solves bug 23659 for MIPS.
Corrected indentation at couple of places.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16916
llvm-svn: 260072
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
user process dyld binary and/or a mach kernel binary image. By
default, it prefers the kernel if it finds both.
But if it finds two kernel binary images (which can happen when
random things are mapped into memory), it may pick the wrong
kernel image.
DynamicLoaderDarwinKernel has heuristics to find a kernel in memory;
once we've established that there is a kernel binary in memory,
call over to that class to see if it can find a kernel address via
its search methods. If it does, use that.
Some minor cleanups to DynamicLoaderDarwinKernel while I was at it.
<rdar://problem/24446112>
llvm-svn: 259983
|
| |
|
|
|
|
|
|
| |
Debuggers and Commands deeper in the bowels of LLDB
NFC
llvm-svn: 259972
|
| |
|
|
|
|
|
|
|
|
| |
created once, bound to a specific CommandInterpreter (and hence a specific Debugger), and then cached for reuse across different Debugger instances
Obviously, if the original Debugger goes away, those commands are holding on to now stale memory, which has the potential to cause crashes
Fixes rdar://24460882
llvm-svn: 259964
|
| |
|
|
|
|
| |
<rdar://problem/24525106>
llvm-svn: 259962
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This relands r259810 with fix for failures on Mac.
Reviewers: spyffe, tfiala
Subscribers: tfiala, lldb-commits
Differential Revision: http://reviews.llvm.org/D16900
llvm-svn: 259902
|
| |
|
|
|
|
|
|
| |
This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling return values in ABISysV_arm.
Differential revision: http://reviews.llvm.org/D16627
llvm-svn: 259885
|
| |
|
|
|
|
|
| |
Log confirmed that the we are sometimes timing out on the receive, even though the server is
sending the correct packets.
llvm-svn: 259878
|
| |
|
|
|
|
|
| |
also add some logging about where lldb is lookin for a kernel as it connects.
<rdar://problem/24454582>
llvm-svn: 259865
|
| |
|
|
|
|
|
|
|
|
| |
process dyld
or mach kernel binary are found, and if there are multiples of them found within a single
corefile.
<rdar://problem/24446112>
llvm-svn: 259850
|
| |
|
|
|
|
|
| |
This allows to find the LLVM's CMake files after moving them in
r259821.
llvm-svn: 259845
|
| |
|
|
| |
llvm-svn: 259838
|
| |
|
|
| |
llvm-svn: 259834
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit 8af14b5f9af68c31ac80945e5b5d56f0a14b38e4.
Reverting as it breaks a few tests on Mac.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16895
llvm-svn: 259823
|
| |
|
|
|
|
|
|
|
|
|
| |
code that was in
GetName actually got the queue name not the thread name and anyway didn't actually work to do
that. So I just deleted it with a fixme.
<rdar://problem/24487554>
llvm-svn: 259818
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
While evaluating expressions when stopped in a class method, there was a
problem of member variables hiding local variables. This was happening
because, in the context of a method, clang already knew about member
variables with their name and assumed that they were the only variables
with those names in scope. Consequently, clang never checks with LLDB
about the possibility of local variables with the same name and goes
wrong. This change addresses the problem by using an artificial
namespace "$__lldb_local_vars". All local variables in scope are
declared in the "$__lldb_expr" method as follows:
using $__lldb_local_vars::<local var 1>;
using $__lldb_local_vars::<local var 2>;
...
This hides the member variables with the same name and forces clang to
enquire about the variables which it thinks are declared in
$__lldb_local_vars. When LLDB notices that clang is enquiring about
variables in $__lldb_local_vars, it looks up local vars and conveys
their information if found. This way, member variables do not hide local
variables, leading to correct evaluation of expressions.
A point to keep in mind is that the above solution does not solve the
problem for one specific case:
namespace N
{
int a;
}
class A
{
public:
void Method();
int a;
};
void
A::Method()
{
using N::a;
...
// Since the above solution only touches locals, it does not
// force clang to enquire about "a" coming from namespace N.
}
Reviewers: clayborg, spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16746
llvm-svn: 259810
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This doesn't attempt to move every decorator. The reason for
this is that it requires touching every single test file to import
decorators.py. I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.
llvm-svn: 259807
|
| |
|
|
|
|
| |
Log message was wrong because an argument was missing.
llvm-svn: 259793
|
| |
|
|
|
|
| |
Test has passed last 200 runs of the build bot.
llvm-svn: 259777
|
| |
|
|
|
|
|
| |
previously, I have marked only one test as flaky, but now I noticed another test failing with the
same error. I am going to assume all of them are flaky.
llvm-svn: 259775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
gdb-remote tests are not able to use the same logging mechanisms as the rest of our tests, and
currently we get no host logs from them, even though the tests themselves have logging
capability. This commit changes that. When user specifies that he would like to log the
gdb-remote channel (--channel gdb-remote argument to dotest.py), we write detailed logs to the
<TEST_ID>-host.log file, just like we would in the case of regular tests. If this argument is not
specified, we only log the serious messages to stderr, which matches the existing behaviour.
Reviewers: tfiala, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16858
llvm-svn: 259774
|
| |
|
|
|
|
|
|
| |
Patch replaces the --refresh flag removed in r258800 with it's own command, 'language renderscript allocation refresh'.
Since there is no reason this functionality should be tied to another command as an option.
The command itself simply re-JITs all our cached information about allocations.
llvm-svn: 259773
|
| |
|
|
|
|
|
|
|
|
| |
variables
as args to a pthread_create function...
<rdar://problem/24485206>
llvm-svn: 259738
|
| |
|
|
| |
llvm-svn: 259724
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D16861
llvm-svn: 259714
|
| |
|
|
| |
llvm-svn: 259689
|
| |
|
|
|
| |
PR: http://reviews.llvm.org/D16818
llvm-svn: 259686
|