Summary:
If a user has their shell set to a non-POSIX conferment shell the TestTerminal.py tests fail because the shell blurb constructed here may not work in their shell.
In my specific case fish-shell (The Friendly Interactive Shell - http://fishshell.com) does not support $?, it instead uses $status (because it is friendly).
This patch removes the assumption of your default shell by running the constructed bash command via "/bin/bash -c ...". This should be safer for users mutating their shell environment.
Reviewers: tfiala
Subscribers: joerg, lldb-commits
Differential Revision: https://reviews.llvm.org/D25750
llvm-svn: 284552
This is better for a number of reasons. Mostly style, but also:
1) Signed-unsigned comparison warnings disappear since there is
no loop index.
2) Iterating with the range-for style gives you back an entry
that has more than just a const char*, so it's more efficient
and more useful.
3) Makes code safter since the type system enforces that it's
impossible to index out of bounds.
llvm-svn: 283413
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
This patch also marks the const char* versions as =delete to prevent
their use. This has the potential to cause build breakages on some
platforms which I can't compile. I have tested on Windows, Linux,
and OSX. Best practices for fixing broken callsites are outlined in
Args.h in a comment above the deleted function declarations.
Eventually we can remove these =delete declarations, but for now they
are important to make sure that all implicit conversions from
const char * are manually audited to make sure that they do not invoke a
conversion from nullptr.
llvm-svn: 281919
macro, so writing ::dispatch_release did not work as expected.
Remove the global anon namespace :: designation; the header will
get us the correct declaration.
llvm-svn: 280903
*** 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
This code represents the Week of Code work I did on bringing up
lldb-server LLGS support for Darwin. It does not include the
Xcode project changes needed, as we don't want to throw that switch
until more support is implemented (i.e. this change is inert, no
build systems use it yet. I've verified on Ubuntu 16.04, macOS
Xcode and macOS cmake builds).
This change does some minimal refactoring of code that is shared
with the Linux LLGS portion, moving it from NativeProcessLinux into
NativeProcessProtocol. That code is also used by NativeProcessDarwin.
Current state on Darwin:
* Process launching is implemented. (Attach is not).
Launching on devices has not yet been tested (FBS/BKS might
need a bit of work).
* Inferior waitpid monitoring and communication of exit status
via MainLoop callback is implemented.
* Memory read/write, breakpoints, thread register context, etc.
are not yet implemented. This impacts process stop/resume, as
the initial launch suspended immediately starts the process
up and running because it doesn't know it is supposed to remain
stopped.
* I implemented the equivalent of MachThreadList as
NativeThreadListDarwin, in anticipation that we might want to
factor out common parts into NativeThreadList{Protocol} and share
some code here. After writing it, though, the fallout from merging
Mach Task/Process into a single concept plus some other minor
changes makes the whole NativeThreadListDarwin concept nothing more
than dead weight. I am likely going to get rid of this class and
just manage it directly in NativeProcessDarwin, much like I did
for NativeProcessLinux.
* There is a stub-out call for starting a STDIO thread. That will
go away and adopt the MainLoop pselect-based IOObject reading.
I am developing the fully-integrated changes in the following repo,
which contains the necessary Xcode bits and the glue that enables
lldb-debugserver on a macOS system:
https://github.com/tfiala/lldb/tree/llgs-darwin
This change also breaks out a few of the lldb-server tests into
their own directory, and adds some $qHostInfo tests (not sure why
I didn't write those tests back when I initially implemented that
on the Linux side).
llvm-svn: 280604
gettimeofday() isn't defined without a special header. Rather
than rely on C apis, let's just use modern C++11 to do this
portably on all platforms using std::chrono.
llvm-svn: 278182
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
It only contained a reimplementation of std::to_string, which I have replaced with usages of
pre-existing llvm::to_string (also, injecting members into the std namespace is evil).
llvm-svn: 278000
Summary:
This is supposed to find the python lib dir and seems like it's just
been copied twice by mistake.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22891
llvm-svn: 277060
This finally removes the use of the Mutex and Condition classes. This is an
intricate patch as the Mutex and Condition classes were tied together.
Furthermore, many places had slightly differing uses of time values. Convert
timeout values to relative everywhere to permit the use of
std::chrono::duration, which is required for the use of
std::condition_variable's timeout. Adjust all Condition and related Mutex
classes over to std::{,recursive_}mutex and std::condition_variable.
This change primarily comes at the cost of breaking the TracingMutex which was
based around the Mutex class. It would be possible to write a wrapper to
provide similar functionality, but that is beyond the scope of this change.
llvm-svn: 277011
that may be embedded in the Contents/Resources subdir of a dSYM
bundle. These allow for the specification of a build-time path
to debug-time path remapping for source files. Files may be built
in /BuildDirectory/sources/project-100 but when the debugger is
run, they're actually found via ~sources/project-100 - this plist
allows for that remapping through the DBGBuildSourcePath and
DBGSourcePath keys.
This patch adds support for a new DBGSourcePathRemapping
dictionary in the plist where the keys are the build-time paths
and the values are the debug-time paths that they should be
remapped to. There are instances were we have multiple possible
build-time paths that need to be included, so the dictionary was
required.
<rdar://problem/26725174>
llvm-svn: 276729
Summary:
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroid, used on android for launching all other kinds of processes
These have over time acquired support for various launch options, but neither supported all of
them. I now replace them with a single implementation ProcessLauncherLinux, which supports all
the options the individual versions supported and set it to be used to launch all processes on
linux.
This also works around the ETXTBSY issue on android when the process is started from the platform
instance, as that used to go through the version which did not contain the workaround.
Reviewers: tberghammer
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D22457
llvm-svn: 276288
trade-offs. When LLDB's multi-line editing support was first introduced
for expressions / REPL contexts the behavior was as follows:
* The Return key is treated as a line-break except at the end of the input
buffer, where a completeness test is applied
This worked well enough when writing code, and makes it trivial to insert
new lines above code you've already typed. Just use cursor navigation to
move up and type freely. Where it was awkward is that the gesture to insert
a line break and end editing is conflated for most people. Sometimes you
want Return to end the editing session and other times you want to insert
a line break.
This commit changes the behavior as follows:
* The Return key is treated as the end of editing except at the end of the
input buffer, where a completeness test is applied
* The Meta+Return sequence is always treated as a line break. This is
consistent with conventions in Facebook and elsewhere since
Alt/Option+Return is often mapped to Meta+Return. The unfortunate
exception is on macOS where this *can* be the case, but isn't by
default. Sigh.
Note that by design both before and after the patch pasting a Return
character always introduces a line break.
<rdar://problem/26886287>
llvm-svn: 275482
for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll
need to look at this more closely before re-committing. (passed OK on
macOS ;)
llvm-svn: 273531
There's uses of "macosx" that will be more tricky to
change, like in triples (e.g. "x86_64-apple-macosx10.11") -
for now I'm just updating source comments and strings printed
for humans.
llvm-svn: 273524
Summary:
In the case of client sockets, we are not binding to a specific port, so we
should be able to just request a new one. Disregarding refactors, this code
has been here since the initial LLDB checkin, so I was unable to figure out
whether it was added as a fix for a specific problem, or just for symmetry
with server sockets, but I see no side-effect from removing it now. I was
still able to create 10000 connections within a couple of seconds, so I think
it's unlikely we will exhaust the port space (previously, I would get an
error after a couple thousand connections).
This fixes an occasional issue with connecting to the android debug bridge
deamon on OSX when running the test suite, which would occasionaly fail with
EADDRINUSE. My best guess is that this was happening because two processes
were assigned the same client port number, and then things blew up because
they were both trying to connect to the same ADB server port. I have not
observed this issue happening on Linux or Windows.
Reviewers: clayborg
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D21088
llvm-svn: 272041
When USE_SETUPTERM_WORKAROUND is enabled, we were calling setupterm() multiple times and leaking memory on each subsequent call. This is now fixed by calling setupterm() once in the constructor and tracking if we have already setup a terminal for a file descriptor.
Calls to "el_set (m_editline, EL_ADDFN, ..." were leaking memory. If we switch over to call el_wset with wide strings when LLDB_EDITLINE_USE_WCHAR is set, then we no longer leak memory each time we construct a new Editline object.
The calls to "el_set (m_editline, EL_ADDFN, ..." were changed over to call "el_wset (m_editline, EL_ADDFN, ...". Note that when LLDB_EDITLINE_USE_WCHAR is not defined, then el_wset is #define'ed to el_set. All strings are wrapped in EditLineConstString which will use wide strings when needed, and normal C strings when LLDB_EDITLINE_USE_WCHAR is not defined.
<rdar://problem/26677627>
llvm-svn: 272036
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
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
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
Chris Bieneman