> 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 <m...@csr.com> wrote: > 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 actively > experimenting on. Generally, we have heterogenous setups (e.g. XAP+8051, or > 4*XAP+kalimba+8051) etc. > > 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. > > 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. > > 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. > > 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. > > Matt > > > > 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 >> >> > > > 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 > More information can be found at www.csr.com. Keep up to date with CSR on > our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, > YouTube, www.youtube.com/user/CSRplc, Facebook, > www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at > www.twitter.com/CSR_plc. > New for 2014, you can now access the wide range of products powered by > aptX at www.aptx.com. > > _______________________________________________ > 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
