It might be nice to mock up just the debugger command streams we think
are needed/wanted to handle several common usages of the heterogeneous
processor debugging scenarios on this thread before putting any code
behind it. That way we can talk through it a bit with concrete
examples to further illuminate the kinds of changes/support we'll need.
On Wed, Aug 27, 2014 at 11:21 PM, Matthew Gardiner <m...@csr.com
<mailto:m...@csr.com>> wrote:
Yes, a "device" abstraction seems to be the correct controlling
entity. In fact, from an embedded debugging perspective it is
__the__ logical entity which groups "debuggable opportunities"
together. However, when Jim mentions "this coordinating entity
should not be restricted to different devices " and alludes to
control over different targets (which are in __some_way__
associated in the debugging user's mind), but may be running on
different machines etc.; then I think that conceptually we are
still talking about the same thing, but the name "device" then
becomes questionable. I can only really think of something a tad
wooly like "DebugScenario", "DebugSession" or
"DeploymentScenario"... :-(
Yes, the Platform should remain just being the Platform.
Regarding "debuggable opportunities" - solely these are just the
"Target" objects that we already have? (In fact Colin's original
post does in fact just state "that can take multiple targets
together and understand how they operate...").
What's really tricky, I think, is how to make the device/scenario
controlling entity look very generic on the outside, but within be
able to coordinate very target specific activities. It seems that
the debuggable_oppurtunity/target would require some way of
communicating the kind of multi-target features it can support e.g.
CanStopOthers
CanBeUnselectedAsActive
...and so on...
Interested to see how things pan out.
Matt
jing...@apple.com <mailto:jing...@apple.com> wrote:
Right, it seems to me clear that you need two entities.
One knows what targets can be created in a given debugging
scenario, and how to hook up to them. Then you need another
to manage picking some subset of these targets, and
coordinating the processes running in each of them.
The Platform seemed the logical place to do the first job.
However, Matthew is right that at present the Platforms are
homogenous, and more deal with OS details. So maybe it would
be better to keep the Platform more about OS details, then we
could add a "device" abstraction that represents composite
entities with multiple debuggable opportunities, and then each
of these "debuggable opportunities" would have a Platform to
represent the OS like features of this opportunity (need some
good word for this.) That might be a better way to go. Note
that the "debuggable opportunities" are more general than just
different devices on a board. For instance, you could imagine
debugging the kernel, and a user-space process running on that
OS, and coordinating those just as you would a main processor
and a co-processor... To make matters a little confusing, a
"device" might represent all the processes running on a single
OS, since that's not formally different from the more
straightforward device scenario. So in some ways a platform
IS also a device in this sense. Maybe the abstraction is more
a target provider, and the Platform is a homogenous target
provider, in addition to its OS duties, and a device is a
heterogenous target provider?
But in either case, once you've chosen to attach to several
debug sockets, there's the whole business that Matthew
mentions of coordinating the sessions. That is clearly a
whole different kettle of fish from just "what can I attach to".
BTW, this coordinating entity should not be restricted to
different devices. At that level, of course, it is really
about coordinating targets & their process regardless of where
they come from. For instance you'd want to be able to use the
same structure to coordinate debugging message passing or
socket traffic, etc on two user space processes on the same or
different systems. It would also be interesting to model this
coordination in a way that could also be extended to threads
in a single process. Right now, each thread's behavior is
programmed using the ThreadPlans which work only on a per
thread basis and don't make any attempt to coordinate
threads. But it would be useful (and more so when you start
doing keep alive debugging) to have some way to program "when
thread A does X, wait for thread B to do Y..." That isn't
formally different from two processes or several
co-processors. Be interesting to see how much of the
coordination we could make very general.
Jim
On Aug 27, 2014, at 7:55 AM, Todd Fiala <tfi...@google.com
<mailto:tfi...@google.com>> wrote:
Greg and Jim both mentioned using the Platform class
as the place to implement this kind of thing.
I think Jim later mentioned a higher-level concept is
needed to do some of the orchestration that we'd want to
enable, IIRC.
On Tue, Aug 26, 2014 at 11:18 PM, Matthew Gardiner
<m...@csr.com <mailto:m...@csr.com>> wrote:
Hi Colin,
Multiple target debugging is a massive interest to us at
CSR. We design chips with various processor types (e.g.
kalimba, XAP, 8051, ARM etc) and on several of our chips
we have multiple-processors. There are lots of
combinations of setups that we have either already done,
or are actively experimenting on. Generally, we have
heterogenous setups (e.g. XAP+8051, or 4*XAP+kalimba+8051)
etc.
I see that lldb already supports the concept of a target
list, an active target and manual switching between
current targets. However, as Colin alludes, there are
several features associated with multiple-target which
require control from a higher-level.
What we currently have in our existing debuggers is
options of the form, "I'm debugging targets A and B, if A
stops do I want B stop as well?". The answer to that
question is very much specific to that user's current
debug scenario. Of course, getting B to stop if A does, is
best implemented in the hardware, and typically a register
will be available as a mechanism to configure this
feature. In our (CSRs) world probably one of the
processors will have access to the associated hardware
block, and our debugger will talk to this target to access
the feature.
So, of course, if non-active target(s) stops whilst
stepping/running the active one, some notification needs
to be passed up, informing the debug session controller of
this, and determining whether or not to switch active target.
Greg and Jim both mentioned using the Platform class as
the place to implement this kind of thing. However, does
the Platform not only deal in homogenous entities? Is it
correct to use this concept to control different processor
families. With my limited lldb architectural knowledge, I
would have thought that the most likely candidate to
control this is the Debugger object itself.
Matt
Colin Riley wrote:
Has anybody done any work on integrating features into
LLDB to allow for 'meaningful' simultaneous multiple
target debugging? There are various scenarios in which
this is a very valuable feature:
1) coprocessor debugging, in single-process systems (i.e,
embedded DSP alongside say a host CPU core)
2) graphical debugging, e.g. games: ideally you want to be
able to debug the CPU code alongside any GPU workgroups,
and have a single interface to any shared resources such
as memory.
We've done work like this in the past to LLDB, it's not
been contributed back because we couldn't do so for
commercial reasons (and it's not in a state to contribute
back, either). However in the future I think this will
become a 'killer app' feature for LLDB and we should be
planning to support it.
At the moment we can have multiple targets, processes etc
running in an LLDB session. However I am failing to see
any system for communication and interpretation of
multiple targets as a whole. If we take the DSP/CPU
situation, I may be watching a CPU memory location whilst
at the same time single-stepping through the DSP. It's
currently undefined and a bit unknown as to how this
situation would work in LLDB as stands. From what I can
see, it's quite hard to use the current independent target
framework to achieve a meaningful debugging session.
It's as though we'd want some sort of session object, that
can take multiple targets together and understand how they
operate as to achieve some sort of well-defined behaviour
in how it's debugged. I.e, in the DSP/CPU scenario, the
session object would understand the DSP has access to the
CPU memory, and as such, if we're currently on the DSP
single stepping, it would allow a CPU watchpoint event
through to the DSP session, with an ability to switch target.
There are many more items we'd need to allow communication
between. A quick example, we have an LLDB version here
that supports non-stop mode debugging (see
https://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html
- and we _will_ contribute this back). At the moment
stepping through one thread and a breakpoint happens in
another is a bit nasty: LLDB simply switches to whatever
thread id is greater. When this sort of usability issue
exists in a single-target fashion, we may need to look at
extracting this out into some sort of policy system that
targets (and, these theoretical session objects) can use
to decide how to handle certain event situations.
Apologies if this is a bit of a brain dump. It's quite a
complex concept, which is why I think dialogue needs to
start now as it's something as I've mentioned we are
actively doing at Codeplay, but when the time comes to
push upstream, want to do so in a way the community thinks
is valuable. There may be other viewpoints, like 'super
debugservers' that can manage multiple targets and spoof a
single target to LLDB, for example.
Any other opinions or thoughts out there? :)
Colin
Member of the CSR plc group of companies. CSR plc
registered in England and Wales, registered number
4187346, registered office Churchill House, Cambridge
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com
<http://www.csr.com>. Keep up to date with CSR on our
technical blog, www.csr.com/blog
<http://www.csr.com/blog>, CSR people blog,
www.csr.com/people <http://www.csr.com/people>, YouTube,
www.youtube.com/user/CSRplc
<http://www.youtube.com/user/CSRplc>, Facebook,
www.facebook.com/pages/CSR/191038434253534
<http://www.facebook.com/pages/CSR/191038434253534>, or
follow us on Twitter at www.twitter.com/CSR_plc
<http://www.twitter.com/CSR_plc>.
New for 2014, you can now access the wide range of
products powered by aptX at www.aptx.com
<http://www.aptx.com>.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
--
Todd Fiala | Software Engineer | tfi...@google.com
<mailto:tfi...@google.com> | 650-943-3180 <tel:650-943-3180>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu <mailto:lldb-dev@cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
To report this email as spam click
https://www.mailcontrol.com/sr/7FVfGMSArIjGX2PQPOmvUq10po4Wab0lH8f98+JOKsNlI8w+ITj63RgscvXSUhTVZl0TLhIw4en5pl0FDW8fzw==
.
--
Todd Fiala | Software Engineer | tfi...@google.com
<mailto:tfi...@google.com> | 650-943-3180
