> On Aug 26, 2014, at 11:30 AM, Greg Clayton <gclay...@apple.com> 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 > (lldb) r > (lldb) file /bin/cat > (lldb) b free > (lldb) r > > Now two targets are available: > > (lldb) target list > (lldb) target select 0 > (selects /bin/ls target) > (lldb) .... (do commands for /bin/ls target) > (lldb) target select 1 > (selects /bin/cat target) > (lldb) .... (do commands for /bin/cat target) > > We currently don't have anything that allows automatic switching of targets > based on any criteria. If a target 0 stops asynchronously while target 1 is > selected, we print that something happened on target 0, but we don't just > emit a stop into and switch the target automatically. > > So there is pleeeeennnnty of room for improvement and polish. The platform is > a good place to manage two related targets and we should probably expand the > platform to do a lot of this management.
I think the platform should be able to provide the components you could hook up to make a "composite debug session" but then we will need some entity to manage the session once instantiated. I don't think the platform is the right guy to do this latter task. It's more of a singleton that described that things that are available in the platform. It shouldn't do "I've initiated an RPC, and now I'm waiting for the other end to act on it, so I can stop it there." type stuff. That's what a "session manager" or something like that would be for. Jim > > I look forward to hearing from what you come up with. > > And I do believe that a BOF on future directions for LLDB would be a good > idea. We could easily cover: > 1 - lldb-gdbserver along with NativeProcess and NativeThread > 2 - multiple target debugging > 3 - MI interface > 4 - ???? > > Greg > >> On Aug 26, 2014, at 8:47 AM, Colin Riley <co...@codeplay.com> 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 >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
