[lldb-dev] Simultaneous multiple target debugging

[Colin Riley]

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