| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
|
|
|
|
|
|
|
|
| |
SBTarget::SetSectionLoadAddress() is called. Also make sure that the section module is unloaded when SBTarget::ClearSectionLoadAddress() or SBTarget::ClearModuleLoadAddress() is called.
<rdar://problem/25119335>
llvm-svn: 269707
|
|
|
|
|
|
|
|
| |
call.
<rdar://problem/24489419>
llvm-svn: 269686
|
|
|
|
|
|
|
|
| |
are part of a disabled category
Fixes rdar://26202006
llvm-svn: 269673
|
|
|
|
|
|
| |
still seeing very rare timeouts on the buildbot.
llvm-svn: 269648
|
|
|
|
|
|
|
|
| |
NPL now assumes it is running from a single thread now, so its thread-safety is untested
anyway (and if that assumption is broken, we'll have bigger problems (due to ptrace restrictions)
than a couple of missing mutexes).
llvm-svn: 269640
|
|
|
|
|
|
|
| |
Add the Float128 type to the enumeration. Float128 is covered under IEEE754 as
a quad precision floating point value.
llvm-svn: 269599
|
|
|
|
|
|
| |
Clean up some newly introduced -Wformat-pedantic warnings (%p expects a void *).
llvm-svn: 269598
|
|
|
|
|
|
|
|
| |
This is a fix due to the addition of the new DiagnosticSeverity in
LLVMContext.h. This may warrant a change in name to be LLDB specific
but I leave that to the LLDB experts to refactor.
llvm-svn: 269562
|
|
|
|
|
|
|
|
|
| |
Remove XFAIL from some tests that now pass.
Add XFAIL to some tests that now fail.
Fix a crasher where a null pointer check isn't guarded.
Properly handle all types of errors in SymbolFilePDB.
llvm-svn: 269454
|
|
|
|
|
|
|
| |
It is still used by ProcessMonitor::StopMonitoringChildProcess and
ProcessMonitor::StopOpThread.
llvm-svn: 269434
|
|
|
|
| |
llvm-svn: 269421
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The AST contexts are not needed in the server components, and the clang context in particular
pulls in large parts of clang into the binary. Simply removing these two calls reduces the
lldb-server size by about 50%--80%, depending on the architecture and build type.
This should not impact the client parts as the same calls are already present in
SystemInitializerFull.
Reviewers: tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20236
llvm-svn: 269416
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for MIPS
Patch by Nitesh Jain.
Summary: These patch will set clang::TargetOptions::ABI and accordingly code will be generated for MIPS target.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, jaydeep, bhushan
Differential: D18638
llvm-svn: 269407
|
|
|
|
|
|
| |
<rdar://problem/26207478>
llvm-svn: 269378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main issues were:
- Listeners recently were converted over to used by getting a shared pointer to a listener. And when they listened to broadcasters they would get a strong reference added to them meaning the listeners would never go away. This caused memory usage to increase and would cause performance issue if many steps were done.
- The lldb_private::Process private state thread had an issue where if a "stop" contol signal was attempted to be sent to that thread, it could end up not responding in 2 seconds and end up getting cancelled which might cause us to cancel a thread that had a mutex locked and it would deadlock the test.
This change makes broadcasters hold onto weak references to listeners. It also fixes some bad threading code that had races inside of it by making the m_events_mutex be non-recursive and getting rid of fragile use of a Predicate<bool> to say that new events are available, and replacing it with using the m_events_mutex with a new m_events_condition to control access to the events in a safer way.
The private state thread now uses a safer way to communicate that the control event has been received by the private state thread: it makes a EventDataReceipt instance that it attaches to the event that sends the control to the private state thread and used this to synchronize the fact that the private state thread has received the event instead of using a Predicate<bool> to convey the info. When the signal event is received, it will pull the event off of the queue in the private state thread and cause the EventData::DoOnRemoval() to be called, which will signal that the event has been received. This cleans up the signal delivery notification so it doesn't rely on a member variable of the process class to convey the info.
std::shared_ptr<EventDataReceipt> event_receipt_sp(new EventDataReceipt());
m_private_state_control_broadcaster.BroadcastEvent(signal, event_receipt_sp);
<rdar://problem/26256353> Listeners are being kept around longer than they should be due to recent changs
<rdar://problem/26256258> Private process state thread can be cancelled and cause deadlocks in test suite
llvm-svn: 269377
|
|
|
|
|
|
|
|
|
|
| |
This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms).
Patch by cameron314
Differential Revision: http://reviews.llvm.org/D19124
llvm-svn: 269340
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MonitorDebugServerProcess went to a lot of effort to make sure its asynchronous invocation does
not cause any mischief, but it was still not race-free. Specifically, in a quick stop-restart
sequence (like the one in TestAddressBreakpoints) the copying of the process shared pointer via
target_sp->GetProcessSP() was racing with the resetting of the pointer in DeleteCurrentProcess,
as they were both accessing the same shared_ptr object.
To avoid this, I simply pass in a weak_ptr to the process when the callback is created. Locking
this pointer is race-free as they are two separate object even though they point to the same
process instance. This also removes the need for the complicated tap-dance around retrieving the
process pointer.
Reviewers: clayborg
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D20107
llvm-svn: 269281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped.
Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct.
Tests run on Ubuntu 12.04 show no regression.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20135
llvm-svn: 269250
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This replaces the C-style "void *" baton of the child process monitoring functions with a more
C++-like API taking a std::function. The motivation for this was that it was very difficult to
handle the ownership of the object passed into the callback function -- each caller ended up
implementing his own way of doing it, some doing it better than others. With the new API, one can
just pass a smart pointer into the callback and all of the lifetime management will be handled
automatically.
This has enabled me to simplify the rather complicated handshake in Host::RunShellCommand. I have
left handling of MonitorDebugServerProcess (my original motivation for this change) to a separate
commit to reduce the scope of this change.
Reviewers: clayborg, zturner, emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20106
llvm-svn: 269205
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary: The ArchSpec::m_flags will be set based on ELF flag ABI.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, jaydeep, bhushan
Differential: D18858
llvm-svn: 269181
|
|
|
|
|
|
|
|
|
|
| |
reconstruct a compile unit or a function, but it still has a valid symbol - and it can use that in order to figure out the preferential language for lookups
This is not the right thing for all clients (notably the expression parser), so put it in type lookup specific code
Fixes rdar://problem/22422313
llvm-svn: 269095
|
|
|
|
|
|
|
|
|
|
| |
Clear() log message was claiming it was the destructor, which had me very confused when looking
at the log messages. Fix the message, and add a log message to the real destructor.
Also noticed that the destructor was needlessly locking the broadcaster mutex (as Clear was
locking it again anyway), so remove that as well.
llvm-svn: 269058
|
|
|
|
|
|
|
|
| |
IOHandlerLinesUpdated() does nothing, and IOHandlerIsInputComplete should be
implemented but isn't. This means that multiline expressions don't work. This
patch fixes that. Test case to follow in the next commit.
llvm-svn: 268970
|
|
|
|
|
|
|
| |
llvm::Error requires all errors to be handled. Simply checking the whether there was an error is
not enough, you have to actuall call handle(All)Errors, in case there was an error.
llvm-svn: 268906
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|