| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adjusts header file includes for headers and source files
in Core. In doing so, one dependency cycle is eliminated
because all the includes from Core to that project were dead
includes anyway. In places where some files in other projects
were only compiling due to a transitive include from another
header, fixups have been made so that those files also include
the header they need. Tested on Windows and Linux, and plan
to address failures on OSX and FreeBSD after watching the
bots.
llvm-svn: 299714
|
| |
|
|
|
|
|
|
|
| |
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, labath
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: https://reviews.llvm.org/D26233
llvm-svn: 285855
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The following problem was occuring:
- broadcaster B had two listeners: L1 and L2 (thread T1)
- (T1) B has started to broadcast an event, it has locked a shared_ptr to L1 (in
ListenerIterator())
- on another thread T2 the penultimate reference to L1 was destroyed (the transient object in B is
now the last reference)
- (T2) the last reference to L2 was destroyed as well
- (T1) B has finished broadcasting the event to L1 and destroyed the last shared_ptr
- (T1) this triggered the destructor, which called into B->RemoveListener()
- (T1) all pointers in the m_listeners list were now stale, so RemoveListener emptied the list
- (T1) Eventually control returned to the ListenerIterator() for doing broadcasting, which was
still in the middle of iterating through the list
- (T1) Only now, it was holding onto a dangling iterator. BOOM.
I fix this issue by making sure nothing can interfere with the
iterate-and-remove-expired-pointers loop, by moving this logic into a single function, which
first locks (or clears) the whole list and then returns the list of valid and locked Listeners
for further processing. Instead of std::list I use an llvm::SmallVector which should hopefully
offset the fact that we create a copy of the list for the common case where we have only a few
listeners (no heap allocations).
A slight difference in behaviour is that now RemoveListener does not remove an element from the
list -- it only sets it's mask to 0, which means it will be removed during the next iteration of
GetListeners(). This is purely an implementation detail and it should not be externally
noticable.
I was not able to reproduce this bug reliably without inserting sleep statements into the code,
so I do not add a test for it. Instead, I add some unit tests for the functions that I do modify.
Reviewers: clayborg, jingham
Subscribers: tberghammer, lldb-commits
Differential Revision: https://reviews.llvm.org/D23406
llvm-svn: 278664
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 262925
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.
Processes now need to take a ListenerSP, not a Listener&.
This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&. Other than that there should be no functional change.
<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39
llvm-svn: 262863
|
| |
|
|
|
|
| |
other minor fixes.
llvm-svn: 262441
|
| |
|
|
|
|
|
|
|
| |
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
|
| |
|
|
| |
llvm-svn: 228179
|
| |
|
|
|
|
|
| |
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
|
| |
|
|
| |
llvm-svn: 200784
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
|
| |
|
|
|
|
|
|
| |
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
|
| |
|
|
| |
llvm-svn: 153683
|
| |
|
|
|
|
|
|
|
| |
class/event bit set.
Use this to allow the lldb Driver to emit notifications for breakpoint modifications.
<rdar://problem/10619974>
llvm-svn: 150665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
symbol context that represents an inlined function. This function has been
renamed internally to:
bool
SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc,
SymbolContext &next_frame_sc,
Address &next_frame_pc) const;
And externally to:
SBSymbolContext
SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc,
SBAddress &parent_frame_addr) const;
The correct blocks are now correctly calculated.
Switched the stack backtracing engine (in StackFrameList) and the address
context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...)
so all inlined callstacks will match exactly.
llvm-svn: 140910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables prior to running your binary. Zero filled sections now get
section data correctly filled with zeroes when Target::ReadMemory
reads from the object file section data.
Added new option groups and option values for file lists. I still need
to hook up all of the options to "target variable" to allow more complete
introspection by file and shlib.
Added the ability for ValueObjectVariable objects to be created with
only the target as the execution context. This allows them to be read
from the object files through Target::ReadMemory(...).
Added a "virtual Module * GetModule()" function to the ValueObject
class. By default it will look to the parent variable object and
return its module. The module is needed when we have global variables
that have file addresses (virtual addresses that are specific to
module object files) and in turn allows global variables to be displayed
prior to running.
Removed all of the unused proxy object support that bit rotted in
lldb_private::Value.
Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code
with the more efficient "FileSpec::Equal (lhs, rhs)".
Improved logging in GDB remote plug-in.
llvm-svn: 134579
|
| |
|
|
|
|
| |
stack changes.
llvm-svn: 125269
|
| |
|
|
| |
llvm-svn: 125080
|
| |
|
|
| |
llvm-svn: 124086
|
| |
|
|
|
|
| |
broadcasting against hijacking in mid-event delivery.
llvm-svn: 124084
|
| |
|
|
|
|
| |
NULL, instead of registering a NULL listener and to crash later.
llvm-svn: 122429
|
| |
|
|
|
|
|
|
|
|
|
| |
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.
llvm-svn: 118319
|
| |
|
|
|
|
|
|
|
| |
keep the file size a bit smaller.
Exposed SBValue::GetExpressionPath() so SBValue users can get an expression
path for their values.
llvm-svn: 117851
|
| |
|
|
| |
llvm-svn: 116271
|
|
|
llvm-svn: 105619
|
