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 <co...@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@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > -- Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
