[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

[Stephen Wilson]

Greg Clayton <gclayton at apple.com> writes:

> 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.

Ah, OK.  I see now.  I did not realize this was *exclusively* about
pugins to help with OS data structures/address mappings/etc.  On the
first read I was thinking about plugins to help interface with specific
JTAG emulators (one might implement support for a JTAG emulator via a
Process plugin instead of writing a gdb remote server, for example).


Thanks for the comments, that cleared things up for me!


> 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
>



--
steve