<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Yeah, I've been thinking about the different streams you'd need. A
difficult one is a call stack on a platform, with frames on
different ABIs/Targets representing cross-architecture calls. <br>
<br>
If anyone here has ever used the Cell PPU/SPU gdb, which had this
feature, I think you'll agree it's absolute gold in terms of value.<br>
<br>
Sadly I can't attend this years meeting, but I'll write a BOF
proposal and send it in anyway with one of the other Codeplayers
there to host.<br>
<br>
Colin<br>
<br>
<br>
<div class="moz-cite-prefix">On 28/08/2014 15:00, Todd Fiala wrote:<br>
</div>
<blockquote
cite="mid:CAFab17Jsi462tYvK5ZvpF8hz=WW+y=th2MfnFVfXufYbbs3YRA@mail.gmail.com"
type="cite">
<div dir="ltr">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. </div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 27, 2014 at 11:21 PM,
Matthew Gardiner <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:mg11@csr.com"
target="_blank">mg11@csr.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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"... :-(<br>
<br>
Yes, the Platform should remain just being the Platform.<br>
<br>
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...").<br>
<br>
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.<br>
<br>
CanStopOthers<br>
CanBeUnselectedAsActive<br>
...and so on...<br>
<br>
Interested to see how things pan out.<br>
<br>
Matt<br>
<br>
<br>
<a moz-do-not-send="true" href="mailto:jingham@apple.com"
target="_blank">jingham@apple.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
Right, it seems to me clear that you need two
entities.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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".<br>
<br>
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.<br>
<br>
Jim<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On Aug 27, 2014, at 7:55 AM, Todd Fiala <<a
moz-do-not-send="true"
href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Greg and Jim both mentioned using the Platform
class as the place to implement this kind of
thing.<br>
</blockquote>
I think Jim later mentioned a higher-level concept
is needed to do some of the orchestration that we'd
want to enable, IIRC.<br>
<br>
<br>
On Tue, Aug 26, 2014 at 11:18 PM, Matthew Gardiner
<<a moz-do-not-send="true"
href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>>
wrote:<br>
Hi Colin,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Matt<br>
<br>
<br>
<br>
Colin Riley wrote:<br>
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:<br>
<br>
1) coprocessor debugging, in single-process systems
(i.e, embedded DSP alongside say a host CPU core)<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 <a moz-do-not-send="true"
href="https://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html"
target="_blank">https://sourceware.org/gdb/current/onlinedocs/gdb/Non_002dStop-Mode.html</a>
- 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.<br>
<br>
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.<br>
<br>
Any other opinions or thoughts out there? :)<br>
<br>
Colin<br>
<br>
<br>
<br>
<br>
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<br>
More information can be found at <a
moz-do-not-send="true" href="http://www.csr.com"
target="_blank">www.csr.com</a>. Keep up to date
with CSR on our technical blog, <a
moz-do-not-send="true"
href="http://www.csr.com/blog" target="_blank">www.csr.com/blog</a>,
CSR people blog, <a moz-do-not-send="true"
href="http://www.csr.com/people" target="_blank">www.csr.com/people</a>,
YouTube, <a moz-do-not-send="true"
href="http://www.youtube.com/user/CSRplc"
target="_blank">www.youtube.com/user/CSRplc</a>,
Facebook, <a moz-do-not-send="true"
href="http://www.facebook.com/pages/CSR/191038434253534"
target="_blank">www.facebook.com/pages/CSR/191038434253534</a>,
or follow us on Twitter at <a
moz-do-not-send="true"
href="http://www.twitter.com/CSR_plc"
target="_blank">www.twitter.com/CSR_plc</a>.<br>
New for 2014, you can now access the wide range of
products powered by aptX at <a
moz-do-not-send="true" href="http://www.aptx.com"
target="_blank">www.aptx.com</a>.<br>
<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
<br>
<br>
-- <br>
Todd Fiala | Software Engineer | <a
moz-do-not-send="true"
href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>
| <a moz-do-not-send="true"
href="tel:650-943-3180" value="+16509433180"
target="_blank">650-943-3180</a><br>
<br>
_______________________________________________<br>
lldb-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
</blockquote>
<br>
<br>
</div>
</div>
To report this email as spam click <a
moz-do-not-send="true"
href="https://www.mailcontrol.com/sr/7FVfGMSArIjGX2PQPOmvUq10po4Wab0lH8f98+JOKsNlI8w+ITj63RgscvXSUhTVZl0TLhIw4en5pl0FDW8fzw=="
target="_blank">https://www.mailcontrol.com/sr/7FVfGMSArIjGX2PQPOmvUq10po4Wab0lH8f98+JOKsNlI8w+ITj63RgscvXSUhTVZl0TLhIw4en5pl0FDW8fzw==</a>
.<br>
</blockquote>
<br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<table style="color:rgb(136,136,136);font-family:'Times New
Roman'" cellpadding="0" cellspacing="0">
<tbody>
<tr
style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td
style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px"
nowrap="nowrap">Todd Fiala |</td>
<td
style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"
nowrap="nowrap"> Software Engineer |</td>
<td
style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"
nowrap="nowrap"> <a moz-do-not-send="true"
href="mailto:tfiala@google.com"
style="color:rgb(17,85,204)" target="_blank"><span
style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial
initial">tfiala@google.com</span></a> |</td>
<td
style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"
nowrap="nowrap"><font color="#1155cc"> <a
moz-do-not-send="true">650-943-3180</a></font></td>
</tr>
</tbody>
</table>
<br>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
- Colin Riley
Games Technology Director
Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: <a class="moz-txt-link-freetext" href="http://www.codeplay.com">http://www.codeplay.com</a>
Twitter: <a class="moz-txt-link-freetext" href="https://twitter.com/codeplaysoft">https://twitter.com/codeplaysoft</a>
This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY </pre>
</body>
</html>