[lldb-dev] Simultaneous multiple target debugging

[Todd Fiala]

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 <colin at codeplay.com> wrote:

> 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 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
>>
>>
> --
> - Colin Riley
> Games Technology Director
>
> Codeplay Software Ltd
> 45 York Place, Edinburgh, EH1 3HP
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
>
> 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
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140826/0c8a2dcc/attachment.html>