Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.
Reviewers: ovyalov, clayborg
Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11094
llvm-svn: 242101
Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.
After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.
This is a resubmit of r241672, after it was reverted due to build failueres on non-linux
platforms.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10996
llvm-svn: 241796
platform-specific symbols that are not implemented on OS X.
The build error that caused this is
Undefined symbols for architecture x86_64:
"lldb_private::NativeProcessProtocol::Attach(unsigned long long, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::AttachToProcess(unsigned long long) in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
"lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-svn: 241688
Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.
After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10996
llvm-svn: 241672
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
Summary:
GetCurrentDirectory() returns the number of characters copied; 0 is a failure, not a success.
Add implementation for chdir().
Reviewers: zturner
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9300
llvm-svn: 237162
Converts the MAP_PRIVATE and MAP_ANON options to the target platform constants
(on which the call runs) rather than using those of the compiled host.
Test Plan:
Run test suite, the following tests requiring memory allocation / JIT support
begin passing when running mac -> linux:
Test11588.py
TestAnonymous.py
TestBreakpointConditions.py
TestCPPStaticMethods.py
TestCStrings.py
TestCallStdStringFunction.py
TestDataFormatterCpp.py
TestDataFormatterStdList.py
TestExprDoesntBlock.py
TestExprHelpExamples.py
TestFunctionTypes.py
TestPrintfAfterUp.py
TestSBValuePersist.py
TestSetValues.py
Differential Revision: http://reviews.llvm.org/D9511
llvm-svn: 236933
Previously the remote module sepcification was fetched only from the
remote platform. With this CL if we have a remote process then we ask it
if it have any information from a given module. It is required because
on android the dynamic linker only reports the name of the SO file and
the platform can't always find it without a full path (the process can
do it based on /proc/<pid>/maps).
Differential revision: http://reviews.llvm.org/D8547
llvm-svn: 233061
- Add Host::GlobArguments() to perform local-globbing
I implemented this on OSX and Windows in terms of argdumper (Windows implementation is essentially the same as the OSX version + a change in binary name and some string magic)
Other platforms did not specifically chime in, so I left it unimplemented for them for the time being. Please feel free to fill in the blanks
- Add Platform::GlobArguments() to support remote-globbing
For now, no feature change here - but now we have infrastructure to help GDBRemote targets to support globbing - and patches to that effect will follow
No visible feature change
llvm-svn: 230065
When launching argdumper, there are a few problems with the
current logic. First, on Windows, the file is called
argdumper.exe, not argdumper. Second, Windows paths have
backslashes in them, and JSON treats <backslash><char> as an
escape sequence. To fix the second problem, on Windows we
convert backslashes to forward slashes, since backslash isn't
a valid filename character anyway this shouldn't be a problem.
llvm-svn: 229784
Summary:
This does not fix any outstanding issue that I know of, but there is no reason these files should
_not_ have CloseOnExec.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7694
llvm-svn: 229506
Platform holds a smart pointer to each platform object created in a
static variable what cause the platform destructors called only on
program exit when other static variables are not availables. With this
change the destructors are called on lldb_private::Terminate()
+ Fix DebuggerRefCount handling in ScriptInterpreterPython
Differential Revision: http://reviews.llvm.org/D7590
llvm-svn: 228944
Make sure the selected platform is always used
Make sure that the host uses the connect://hostname to connect to both
the lldb-platform and the lldb-gdbserver rather than what the platform
reports as the hostname of the lldb-gdbserver
Make sure that lldb-platform uses the IP address on it's connection
back to the host instead of the hostname that the host sends to it
when launching lldb-gdbserver with the remote host information
Tested on OSX and Linux
llvm-svn: 226712
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
This cleans up a couple of warnings [-Wcovered-switch-default] from the build by
removing the default case from a couple of switches which are fully covered.
This is generally better as it will help identify when a new item is added to
the enumeration but the use sites are not updated.
llvm-svn: 217376
This patch creates a HostInfo class, a static class used to answer
basic queries about the host platform. As part of this change,
some functionality is moved from Host to HostInfo, and relevant
fixups are performed in the rest of the codebase.
This is part of a larger effort to isolate more code in the Host
layer into platform-specific groups, to make it easier to make
platform specific changes for a particular Host without breaking
other hosts.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4963
llvm-svn: 215992
More specifically, this change can be summarized as follows:
1) Makes an lldbHostPosix library which contains code common to
all posix platforms.
2) Creates Host/FileSystem.h which defines a common FileSystem
interface.
3) Implements FileSystem.h in Host/windows and Host/posix.
4) Creates Host/FileCache.h, implemented in Host/common, which
defines a class useful for storing handles to open files needed
by the debugger.
Differential Revision: http://reviews.llvm.org/D4889
llvm-svn: 215775
This reverses out the options validators changes. We'll get these
back in once the changes to the output can be resolved.
Restores broken tests on FreeBSD, Linux, MacOSX.
Changes reverted: r212500, r212317, r212290.
llvm-svn: 212543
The purpose of the OptionValidator is to determine, based on some
arbitrary set of conditions, whether or not a command option is
valid for a given debugger state. An example of this might be
to selectively disable or enable certain command options that
don't apply to a particular platform.
This patch contains no functional change, and does not actually
make use of an OptionValidator for any purpose yet. A follow-up
patch will begin to add the logic and users of OptionValidator.
Reviewed by: Greg Clayton, Jim Ingham
Differential Revision: http://reviews.llvm.org/D4369
llvm-svn: 212290
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
This fixes a number of trivial warnings in the Windows build. This is part of a larger effort to make the Windows build warning-free.
See http://reviews.llvm.org/D3914 for more details.
Change by Zachary Turner
llvm-svn: 209749
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
add a new pure virtual CalculateTrapHandlerSymbolNames() that Platform
subclasses must implement which fills in the function name list with any
trap handlers that are expected on that platform.
llvm-svn: 201364
aka asynchronous signal handlers, which subclasses should fill
in as appropriate. For most Unix user process environments,
the one entry in this list is _sigtramp. For bare-board and
kernel environments, there will be different sets of trap
handlers.
The unwinder needs to know when a frame is a trap handler
because the rules it enforces for the frame "above" the
trap handler is different from most middle-of-the-stack frames.
<rdar://problem/15835846>
llvm-svn: 201300
Chaoren Lin