The advantage of this one is that it has globals and statics in the
variables and runs directly in lldb. It can also show disassembly,
though we don't yet support that.
The disadvantage is that this is yet another plugin that plays fast and
loose with the protocol, so we have to add a bunch more gets.
This required working around some sort of bug where the server returns
an invalid content length. Either that or we are somehow processing the
same message twice with additional escaping? It's really strange.
This introduced more hacks than it should. In particular, the sequence
about stack trace requesting became very messy. When we attach, we don't
instantly get a stopped event. This required making the Pause command
actually work (sort of). In this case we often won't have a proper
current thread.
Instead we sort of request all threads whenever we get a thread event,
thought his is horribly hacky and we should really just use the thread
event as-is. We then attempt to pause ALL threads on pause and continue
requests when we don't know the current thread.
Another issue is that when pausing it's likely we don't have the source
location info for the pause location (something like select() or
whatever), so we only set the current frame to the lowest one we have
source for. This sort of roughly matches what you want.
This whole thing makes it clear that threads and stack trace in separate
panes makes no sense. We need to replicate the hierarchy in the
variables view for threads and stack traces.
This is a mess, with a load of duplication, but it's a step. When you
request a breakpoint, we add one (in state ENABLED). You can then toggle
it again to change to DISABLED. And once more to delete it.
Once we start the debug server, that all changes and we just start
sending the breakpoints directly to the server and updating based on the
responses. This is far from ideal and somewhat jarring, but this
approach allows me to play around with ideas about what the user
experience should look like.
For line-breakpoints we already know it, so just use what we said
originally. For method breakpoints, we have no clue. While some servers
return a line, it could be in any file, so we just ignore them.
This change refactors the way we launch the job and puts it all in an
internal namespace. Having done that, we are able to launch the job from
the python side. This allows us to neatly load a json file, simlar in
format to .vscode's launch.json, but sufficiently different that users
won't just expect the launch.json to work.
This change allows selecting between 2 different adapters to debug the
same c program.
