On Thu, Aug 28, 2014 at 8:30 AM, Colin Riley wrote:
> 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.
>
> If anyone here has ever used the Cell PPU/SPU
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.
If anyone here has ever used the Cell PPU/SPU gdb, which had this
feature, I think you'll agree it's abso
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 illu
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 devic
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
> 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 wrote:
> Hi Colin
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
ac
As Jim stated we have the architecture to support multiple target debugging,
but we haven't done much with it right now.
The current state is you can switch between targets and so stuff:
(lldb) file /bin/ls
(lldb) b malloc
(lldb) r
(lldb) file /bin/cat
(lldb) b free
(lldb) r
Now two targets are
> On Aug 26, 2014, at 11:30 AM, Greg Clayton wrote:
>
> As Jim stated we have the architecture to support multiple target debugging,
> but we haven't done much with it right now.
>
> The current state is you can switch between targets and so stuff:
>
> (lldb) file /bin/ls
> (lldb) b malloc
>
We certainly designed lldb with this possibility in mind, but haven't had any
need for it yet, so the support remains sketchy. Maybe the "Platform" is the
right agent to know how to cons up a conjoint debug session of the sort you
describe. But we lack the entity that would manage such a compo
Hey Colin!
> In fact, would any folk be interested in a BOF session on this topic at
the next meeting?
I would certainly attend if given the opportunity :-)
-Todd
On Tue, Aug 26, 2014 at 9:02 AM, Colin Riley wrote:
> In fact, would any folk be interested in a BOF session on this topic at
> t
In fact, would any folk be interested in a BOF session on this topic at
the next meeting?
On 26/08/2014 16:47, 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 t
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 co
13 matches
Mail list logo
