| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The IsValid calls can try to reconstruct the thread & frame, which can
take various internal locks. This can cause A/B locking issues with
the Target lock, so these calls need to that the Target lock.
llvm-svn: 268828
|
|
|
|
|
|
|
| |
Greg says he doesn't need these asserts anymore and since they cause occasional test suite
crashes, out they go.
llvm-svn: 268827
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
through line 0 code".
That's good 'cause it means all the different kinds of source line stepping won't leave user in the middle of
compiler implementation code or code inlined from odd places, etc. But it turns out that the compiler
also marks functions it MIGHT inline as all being of line 0. That would mean we single step through this code
instead of just stepping out. That is both inefficient, and more error prone 'cause these little nuggets tend
to be bits of hand-written assembly and the like and are hard to step through.
This change just checks and if the entire function is marked with line 0, we step out rather than step through.
<rdar://problem/25966460>
llvm-svn: 268823
|
|
|
|
| |
llvm-svn: 268802
|
|
|
|
|
|
|
| |
Remove the typedef and local structure which was unused. Fixes last of the new
clang warnings in the debugserver build. NFC.
llvm-svn: 268759
|
|
|
|
|
|
|
| |
Explicitly provide an initializer for the std::vector in the constructed type.
Addresses -Wmissing-field-initializers warnings from clang. NFC.
llvm-svn: 268758
|
|
|
|
|
|
|
| |
Remove the unnecessary use of std::move to permit the compiler to perform NVRO
instead. Fixes more warnings from clang. NFC.
llvm-svn: 268757
|
|
|
|
|
|
|
|
| |
Remove a couple of `default` cases from switches which are covered. This is
beneficial since it would allow the compiler to indicate when a new enum value
is added and the switch is not updated. Fixes some warnings from clang. NFC.
llvm-svn: 268756
|
|
|
|
|
|
|
| |
Perform explicit casts for the log message to address some `-Wformat-pedantic`
warnings from clang. NFC.
llvm-svn: 268755
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19991
llvm-svn: 268750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Allow LanguageRuntimes to return an error if they fail in the course of 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"
I need to think about what I want to do in this space more carefully - this attempt might be too heavy of a hammer for the nail I am trying to fix, and I don't want to leave it in while I ponder
llvm-svn: 268686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change addresses a hang/segfault in TestEvents.py. The threads that
run the listener loops now do an SBListener.Clear() before they wrap up
their work. This prevents the test from trying to clean up the
SBListener too late.
There is a separate issue here which is that we should prevent this
clean-up time lock-up, but that is out of scope for this particular
change. I'd like to get these tests back and running the normal flow
rather than skipping them.
This addresses:
llvm.org/pr25924 (at least, the OS X side, although I suspect this will
also address Linux)
http://reviews.llvm.org/D19983
reviewed by: Jim Ingham
llvm-svn: 268653
|
|
|
|
|
|
|
| |
This was broken in the grand configuration change. Now
using -# works again.
llvm-svn: 268638
|
|
|
|
|
|
|
|
|
| |
The function only avaibleble when python is enabled. Guard the new call
in the Java plugin with LLDB_DISABLE_PYTHON until we can change
AddCXXSynthetic to be available in all case to get the build bots green
again.
llvm-svn: 268626
|
|
|
|
|
|
|
| |
now that the timeout actually means something, we see that sometimes adb is just really slow in
replying to the DONE packet during file push. Give it more time to complete.
llvm-svn: 268623
|
|
|
|
|
|
| |
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
|