[Lldb-commits] [lldb] r125815 - in /lldb/trunk: include/lldb/Core/PluginManager.h include/lldb/Target/Process.h include/lldb/Target/Target.h include/lldb/lldb-enumerations.h source/Core/PluginManager.cpp source/Core/UserSettingsController.cpp source/Interpreter/CommandInterpreter.cpp source/Target/Process.cpp source/Target/Target.cpp source/lldb.cpp

[Greg Clayton]

On Feb 17, 2011, at 8:22 PM, Stephen Wilson wrote:

> 
> Hi Greg,
> 
> Greg Clayton <gclayton at apple.com> writes:
> 
>> Author: gclayton
>> Date: Thu Feb 17 19:44:25 2011
>> New Revision: 125815
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=125815&view=rev
>> Log:
>> Added new target instance settings for execution settings:
>> 
>> Targets can now specify some additional parameters for when we debug
>> executables that can help with plug-in selection:
>> 
>> target.execution-level = auto | user | kernel
>> target.execution-mode  = auto | dynamic | static
>> target.execution-os-type = auto | none | halted | live
>> 
>> On some systems, the binaries that are created are the same wether you use
>> them to debug a kernel, or a user space program. Many times inspecting an
>> object file can reveal what an executable should be. For these cases we can
>> now be a little more complete by specifying wether to detect all of these
>> things automatically (inspect the main executable file and select a plug-in
>> accordingly), or manually to force the selection of certain plug-ins.
>> 
>> To do this we now allow the specficifation of wether one is debugging a user
>> space program (target.execution-level = user) or a kernel program
>> (target.execution-level = kernel).
>> 
>> We can also specify if we want to debug a program where shared libraries
>> are dynamically loaded using a DynamicLoader plug-in
>> (target.execution-mode = dynamic), or wether we will treat all symbol files
>> as already linked at the correct address (target.execution-mode = static).
>> 
>> We can also specify if the inferior we are debugging is being debugged on
>> a bare board (target.execution-os-type = none), or debugging an OS where
>> we have a JTAG or other direct connection to the inferior stops the entire
>> OS (target.execution-os-type = halted), or if we are debugging a program on
>> something that has live debug services (target.execution-os-type = live).
> 
> 
> Could you say a few more words about the semantics for the
> execution-os-type?  For example, I would think that bare-board debugging
> (target.execution-os-type = none) would include JTAG scenarios and thus
> could overlap with target.execution-os-type = halted.

These settings are designed to help us figure out which plug-ins to load. The target.execution-os-type = none setting is there for when you won't want any plug-ins to load the would help track down any OS entities (processes or threads).  

In the future, people will be able to have ProcessHelper plug-ins (the name is not set in stone yet) that can look through memory at data structures and figure out which processes, threads and other OS features might be present. When the target.execution-os-type = none is used, it lets the debugger know that even say for an executable that might appear to be a user or kernel executable, we are not going to try and match it up with a ProcessHelper plug-in that knows how to handle i386-apple-kernel executables. 

The target.execution-os-type = halted is letting us know that we expect to be debugging a halted OS and there should be some sort of plug-in that can help us track down the OS entities.

target.execution-os-type = none is for when there is no OS that we should be attempting to track down.

This is also about user choice prior to connecting since many times when connecting to a JTAG board or to a simulator, there is no file that is given in advance, so this allows users to select their settings prior to connecting. Also if the automatic detection is getting in the way, these settings allow users to override what might automatically happen.

> I can't shake the feeling that what we need here is a
> "target.execution-type" where the setting is the logical OR of one or
> more flags.  On bit could cover "stop the world" debugging scenarios
> like JTAG without implying anything specific about the operating system
> context.  Other bits could communicate the precence of an OS and
> additional features it may or may not possess.

That is essentially what we have here, but things are split up into multiple members. We can combine these things into a single bitfield or uint32_t value, but they are currently separated. 

I am open to suggestions if you have a complete suggestion to offer, This stuff is very preliminary and after thinking about it and going over all the scenarios this is the best we came up with. Again, feel free to suggest any changes you would like to see and we can integrate them after discussing any needed changes!

Greg Clayton