Stop messages from being emitted out of order when detaching.

llvm-svn: 202756

Merging the iohandler branch back into main.

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 embe

Merging the iohandler branch back into main.

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

show more ...

Centralized the launching of a process into Target::Launch()

While investigating test suite failures when running the test suite remotely, I noticed we had 3 copies of code that launched a process:

Centralized the launching of a process into Target::Launch()

While investigating test suite failures when running the test suite remotely, I noticed we had 3 copies of code that launched a process:
1 - in "process launch" command
2 - SBTarget::Launch() with args
3 - SBTarget::Launch() with SBLaunchInfo

"process launch" was launching through the platform if it was supported (this is needed for remote debugging) and the 2 and 3 were not.

Now all code is in one place.

llvm-svn: 197247

show more ...

Only use a PTY master/slave when launching for local processes.

llvm-svn: 195483

Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state
- By default, the above function will wait for at least one event
- Set wait_always=false to make

Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state
- By default, the above function will wait for at least one event
- Set wait_always=false to make the function return immediately if the process is already stopped

llvm-svn: 192301

show more ...

Add OptionParser.h

llvm-svn: 190063

<rdar://problem/13700260>

Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process'

<rdar://problem/13700260>

Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state.

llvm-svn: 181651

show more ...

Recommitting r180831 with trivial fix - remember to return errors if you compute.

llvm-svn: 180898

Reverting 180831 as it crashes TestDefaultConstructorForAPIObjects.py

llvm-svn: 180868

Added an option to "process detach" to keep the process stopped, if the process plugin (or in the
case of ProcessGDBRemote the stub we are talking to) know how to do that.

rdar://problem/13680832

l

Added an option to "process detach" to keep the process stopped, if the process plugin (or in the
case of ProcessGDBRemote the stub we are talking to) know how to do that.

rdar://problem/13680832

llvm-svn: 180831

show more ...

“process launch” should “detach” not “kill” if the current process was one we attached to.
“process attach” should ask the same questions as process launch if there is a current process.
“process con

“process launch” should “detach” not “kill” if the current process was one we attached to.
“process attach” should ask the same questions as process launch if there is a current process.
“process connect” then “process launch” or “process attach” should actually work.

<rdar://problem/13524210>
<rdar://problem/13524208>
<rdar://problem/13488919>

llvm-svn: 178324

show more ...

Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where
hitting auto-continue signals while running a thread plan would cause us to lose control of t

Reworked the way Process::RunThreadPlan and the ThreadPlanCallFunction interoperate to fix problems where
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug
session.

<rdar://problem/12993641>

llvm-svn: 174793

show more ...

<rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our

<rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.

llvm-svn: 173463

show more ...

Fixed an issue the "process plugin" proxy object was trying to use the m_exe_ctx when it wasn't ok to do so.

llvm-svn: 172014

Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:

enum
{
//---------------------------------------------------------------

Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:

enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};

Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.

llvm-svn: 171990

show more ...

Fix typo in error message (print requested URL instead of command name when plugin missing)

llvm-svn: 170447

Removed the == and != operators from ArchSpec, since
equality can be strict or loose and we want code to
explicitly choose one or the other.

Also renamed the Compare function to IsEqualTo, to
avoid

Removed the == and != operators from ArchSpec, since
equality can be strict or loose and we want code to
explicitly choose one or the other.

Also renamed the Compare function to IsEqualTo, to
avoid confusion.

<rdar://problem/12856749>

llvm-svn: 170152

show more ...

Fix Linux build warnings due to redefinition of macros:
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)

Fix Linux build warnings due to redefinition of macros:
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)

Patch by Matt Kopec!

llvm-svn: 169341

show more ...

<rdar://problem/12798131>

Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added

<rdar://problem/12798131>

Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite.

This fix does the following:
- make sure all short options are treated as "int"
- make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired
- fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates
- fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value

llvm-svn: 169189

show more ...

Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

llvm-svn: 168945

This is a fix for the command option parser.

There was a generic catch-all type for path arguments
called "eArgTypePath," and a specialized version
called "eArgTypeFilename." It turns out all the
c

This is a fix for the command option parser.

There was a generic catch-all type for path arguments
called "eArgTypePath," and a specialized version
called "eArgTypeFilename." It turns out all the
cases where we used eArgTypePath we could have
used Filename or we explicitly meant a directory.

I changed Path to DirectoryName, made it use the
directory completer, and rationalized the uses of
Path.

<rdar://problem/12559915>

llvm-svn: 166533

show more ...

<rdar://problem/12462048>
<rdar://problem/12068650>

More fixes to how we handle paths that are used to create a target.

This modification centralizes the location where and how what the user specif

<rdar://problem/12462048>
<rdar://problem/12068650>

More fixes to how we handle paths that are used to create a target.

This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".

llvm-svn: 166186

show more ...

<rdar://problem/12462048>

LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:

target.arg0 (string) =

There is also the program argument that are

<rdar://problem/12462048>

LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:

target.arg0 (string) =

There is also the program argument that are separate from the first argument that have existed for a while:

target.run-args (arguments) =

When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args

Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.

llvm-svn: 166137

show more ...

<rdar://problem/12491387>

I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:

virtual CommandObject *
GetPluginComma

<rdar://problem/12491387>

I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:

virtual CommandObject *
GetPluginCommandObject();

This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented!

llvm-svn: 165861

show more ...

Add support for debugging KASLR kernels via kdp (the kernel being
loaded at a random offset).

To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel r

Add support for debugging KASLR kernels via kdp (the kernel being
loaded at a random offset).

To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.

I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.

<rdar://problem/7714201>

llvm-svn: 164881

show more ...