| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19540
llvm-svn: 268622
|
|
|
|
|
|
|
| |
the test should no longer crash, but we need to investigate why ToT clang still generates debug
info we don't understand.
llvm-svn: 268619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AdbClient would spin in a loop in ReadAllBytes in case the remote end was closed before reading
the requested number of bytes. Make sure we return an error in this case instead.
Reviewers: ovyalov
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D19916
llvm-svn: 268617
|
|
|
|
| |
llvm-svn: 268616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We were trying to get a DWARFDIE from a CompileUnit belonging to a DWO file. However, this
function does not understand the die encoding used by the DWO files. Instead use GetDIE on the
SymbolFileDWARF, which is overriden in DWO to do the right thing.
Reviewers: clayborg, tberghammer
Subscribers: lldb-commits, ovyalov
Differential Revision: http://reviews.llvm.org/D19927
llvm-svn: 268615
|
|
|
|
|
|
|
|
|
|
|
|
| |
dynamic type discovery
This is not meant to report that a value doesn't have a dynamic type - it is only meant as a mechanism to propagate actual type discovery issues (e.g. malformed type metadata for languages that have such a notion)
This information is used by ValueObjectDynamic to set its own m_error, which is a fairly sharp and heavyweight tool to begin with
For the time being, this is an architectural improvement but a practical no-op as no existing runtimes are actually setting errors
llvm-svn: 268591
|
|
|
|
|
|
|
|
| |
not to log depending on whether the types log is enabled
This can prove helpful in debugging issues with that retrieval even if LLDB wasn't compiled with the magic macros defined
llvm-svn: 268587
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19943
llvm-svn: 268574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Fixed semicolon placement in the lambda in the test itself.
2. Fixed lldbinline tests in general so that we don't attempt tests on platforms that don't use the given type of debug info. (For example, no DWO tests on Windows.) This fixes one of the two failures on Windows. (TestLambdas.py was the only inline test that wasn't XFailed or skipped on Windows.)
3. Set the error string in IRInterpreter::CanInterpret so that the caller doesn't print (null) instead of an explanation. I don't entirely understand the error, so feel free to suggest a better wording.
4. XFailed the test on Windows. The interpreter won't evaluate the lambda because the module has multiple function bodies. I don't exactly understand why that's a problem for the interpreter nor why the problem arises only on Windows.
Differential Revision: http://reviews.llvm.org/D19606
llvm-svn: 268573
|
|
|
|
| |
llvm-svn: 268566
|
|
|
|
|
|
|
|
| |
We don't want a mutex in debugger as it will cause A/B locking issues with the lldb_private::Target's mutex, but we do need to stop two threads from doing Debugger::Clear at the same time. We have seen issues with this with the C++ global destructor chain where the global debugger list is being destroyed and the Debugger::~Debugger() is calling it while another thread was in the middle of running that function.
<rdar://problem/26098913>
llvm-svn: 268563
|
|
|
|
| |
llvm-svn: 268562
|
|
|
|
|
|
| |
<rdar://problem/25959792>
llvm-svn: 268559
|
|
|
|
|
|
|
| |
r268544 moves all PDB reading code into a pdb namespace,
so LLDB needs to be updated to take this into account.
llvm-svn: 268545
|
|
|
|
| |
llvm-svn: 268520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
should not be used for this module -- for use when an ObjectFile
knows that it does not have meaningful or accurate function start
addresses.
More commonly, it is not clear that function start addresses are
missing in a module. There are certain cases on Mac OS X where we
can tell that a Mach-O binary has been stripped of this essential
information, and the unwinder can end up emulating many megabytes
of instructions for a single "function" in the binary.
When a Mach-O binary is missing both an LC_FUNCTION_STARTS load
command (very unusual) and an eh_frame section, then we will assume
it has also been stripped of symbols and that instruction emulation
will not be useful on this module.
<rdar://problem/25988067>
llvm-svn: 268475
|
|
|
|
|
|
|
|
|
|
|
| |
the field_begin that starts the copy or it won't do anything.
This causes failures, but only in complex apps, I haven't found
a reduced test case for this yet.
<rdar://problem/21951798>
llvm-svn: 268467
|
|
|
|
| |
llvm-svn: 268433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As these are really testing separate issues, they should be run as separate
tests.
Reviewers: zturner, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19690
llvm-svn: 268397
|
|
|
|
|
|
|
| |
This reverts commit r268380 as it breaks windows build (I forgot to make neccesary adjustments to
ConnectionGenericFileWindows).
llvm-svn: 268384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AdbClient was attempting to handle the case where the socket input arrived in pieces, but it was
failing to handle the case where the connection was closed before that happened. In this case, it
would just spin in an infinite loop calling Connection::Read. (This was also the cause of the
spurious timeouts on the darwin->android buildbot. The exact cause of the premature EOF remains
to be investigated, but is likely a server bug.)
Since this wait-for-a-certain-number-of-bytes seems like a useful functionality to have, I am
moving it (with the infinite loop fixed) to the Connection class, and adding an
appropriate test for it.
Reviewers: clayborg, zturner, ovyalov
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D19533
llvm-svn: 268380
|
|
|
|
| |
llvm-svn: 268338
|
|
|
|
|
|
| |
<rdar://problem/24728287>
llvm-svn: 268325
|
|
|
|
|
|
|
|
| |
command names for nested command objects
rdar://problem/26020072
llvm-svn: 268309
|
|
|
|
|
|
|
|
|
| |
Also added a data formatter that presents them as structs if you use frame
variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
|
|
|
|
| |
llvm-svn: 268303
|
|
|
|
|
|
| |
customization on the generated value
llvm-svn: 268274
|
|
|
|
|
|
| |
children yesterday. Do so now
llvm-svn: 268263
|
|
|
|
|
|
| |
typename for display
llvm-svn: 268208
|
|
|
|
| |
llvm-svn: 268194
|
|
|
|
| |
llvm-svn: 268193
|
|
|
|
| |
llvm-svn: 268192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Building HEAD of LLDB fails in linking against DebugInfoPDB. It also prints the following warning:
```
CMake Warning (dev) in source/Plugins/SymbolFile/PDB/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
Target "lldbPluginSymbolFilePDB" has an INTERFACE_LINK_LIBRARIES property.
This should be preferred as the source of the link interface for this
library but because CMP0022 is not set CMake is ignoring the property and
using the link implementation as the link interface instead.
INTERFACE_LINK_LIBRARIES:
LLVMDebugInfoPDB
Link implementation:
(empty)
```
CMP0022 was introduced in CMake-2.8.11, bump minimal required version from 2.8 to 3.0 to gain more useful features like libexecinfo(3) detection on NetBSD.
Reviewers: emaste, zturner, labath
Subscribers: zturner, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D19685
llvm-svn: 268191
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19751
llvm-svn: 268135
|
|
|
|
|
|
|
|
|
| |
a bitfield member doesn't lie within the bit bounds of the type itself, just leave it out so we don't get clang asserting and killing our IDE when it gets unhappy with the information.
https://llvm.org/bugs/show_bug.cgi?id=27515
<rdar://problem/21082998>
llvm-svn: 268110
|
|
|
|
|
|
| |
values showing up as we would find static variables in the Block and also in the compile unit. We now make sure a variable hasn't been added to the list before we add it.
llvm-svn: 268101
|
|
|
|
|
|
|
|
| |
or asserting.
<rdar://problem/23776428>
llvm-svn: 268098
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In templated const functions, trying to run an expression would produce the
error
error: out-of-line definition of '$__lldb_expr' does not match any declaration
in 'foo' member declaration does not match because it is const qualified
error: 1 error parsing expression
which is no good. It turned out we don't actually need to worry about "const,"
we just need to be consistent about the declaration of the expression and the
FunctionDecl we inject into the class for "this."
Also added a test case.
<rdar://problem/24985958>
llvm-svn: 268083
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19489
llvm-svn: 267931
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Started failing after rL267895.
Possibly related to http://llvm.org/pr27510.
Reviewers: labath, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19680
llvm-svn: 267923
|
|
|
|
|
|
| |
global variables.
llvm-svn: 267894
|
|
|
|
|
|
|
| |
The test seems to pass now, and the test does not seem to be doing anything unusual, so I don't
expect it to cause problems.
llvm-svn: 267867
|
|
|
|
|
|
|
|
|
|
| |
$__lldb_expr."
This reverts commit r267833 as it breaks the build. It looks like some work in progress got
committed together with the actual fix, but I'm not sure which one is which, so I'll revert the
whole patch and let author resumbit it after fixing the build error.
llvm-svn: 267861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in ClangExpressionDeclMap::FindExternalVisibleDecls figures out what the token
means, and adds the namespace to the lookup context, but since it doesn't mark it as
special in the search context, we go on to pass the name $__lldb_local_vars to the ASTSource
for further lookup. Unless we've done our job wrong, those lookups will always fail, but
the can be costly.
So I added a bit to m_found & use that to short-circuit the lookup.
<rdar://problem/25613384>
llvm-svn: 267842
|
|
|
|
|
|
|
|
|
|
|
|
| |
within a source file.
This isn't done, I need to make the name match smarter (right now it requires an
exact match which is annoying for methods of a class in a namespace.
Also, though we use it in tests all over the place, it doesn't look like we have
a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch.
llvm-svn: 267834
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In templated const functions, trying to run an expression would produce the
error
error: out-of-line definition of '$__lldb_expr' does not match any declaration in 'foo'
member declaration does not match because it is const qualified
error: 1 error parsing expression
which is no good. It turned out we don't actually need to worry about "const,"
we just need to be consistent about the declaration of the expression and the
FunctionDecl we inject into the class for "this."
Also added a test case.
<rdar://problem/24985958>
llvm-svn: 267833
|
|
|
|
|
|
|
|
| |
There's an open bug with calling functions in the inferior. And Windows doesn't have the POSIX function getpid().
Differential Revision: http://reviews.llvm.org/D19626
llvm-svn: 267800
|
|
|
|
|
|
| |
<rdar://problem/25785338>
llvm-svn: 267768
|
|
|
|
| |
llvm-svn: 267749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the remote uses svr4 packets to communicate library info,
the LoadUnload tests will fail, as lldb only used the basename
for modules, causing problems when two modules have the same basename.
Using absolute path as sent by the remote will ensure that lldb
locates the module from the correct directory when there are overlapping
basenames. When debugging a remote process, LoadModuleAtAddress will still
fall back to using basename and module_search_paths, so we don't
need to worry about using absolute paths in this case.
Reviewers: ADodds, jasonmolenda, clayborg, ovyalov
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D19557
llvm-svn: 267741
|