GitLab

technically, it would be cleaner to handle that in the adapters,
but it is a lot of duplicated code without any gain.

if the respective view is enabled, the manager will request the
initial update in some unholy state, probably AdapterStarting -
when gdb isn't up yet.

the assumption is that pending breakpoints will only be resolved when
the source list changes. consequently it is pointless to update just
one of them.

there seems to be no reason for delaying the display because
of -break-list

Apple gdb does not give any ^done or ^error for unknown command.
Work around by using -interpreter-exec console.

synchroneous mode

doesn't seem to serve any purpose at this time.

and the latter is auto-tiggered by pretty much any breakpoint event.
this will kinda ensure that the markers are up-to date.

those pesky nested event loops ...

i pondered various other scenarios (in particular, the adapter or
gdb crashing while the nested loop is running), but did not discover
serious side effects of it, so i'm not trying to handle it specially.

Handle QVariantList within dumpers, as gdb does not resolve
typedefs. Disconnect the gdb process on exit, one more round
of event loop when quitting.

this isn't bullet-proof - integrated error messages are already
translated. but at least we know *where* the message comes from.
also, saves the translators from some pretty useless work.

- Remove old rfcomm process handler from TrkGdbAdapter, use
  Bluetooth starter instead
- Synchronous connection, remove waitForTrkConnect()
- Move gdb start into Trk version answer, pass on
  settings id hint
- Prevent exit crash triggered by signal gdbProcessFinished()
- Set DebuggerNotReady correctly on AdapterStartFailed when no
  gdb is started yet

specifically, we need it iff the user gets to see the stopped inferior

seems to have been an artifact from an early version. it was
unreachable (gdb going wild notwithstanding), and would do
Strange Stuff (TM) if it ever were reached.

first, try harder to have an up-to-date sources list.
then, use the mapping whenever applicable and available.

when queuing up commands, don't interrupt if we are already waiting
for interruption. that will be the case when other commands area already
queued.

if there are already commands queued for running after temporary break,
then *all* commands must queued up or their order will change.

*in theory*, there is no way we could at any point know more than gdb
knows and tells us about full path names. let's see what practice shows
for the gdbs we support ...

and fix typo in debug message :)=

this is an epic fail for older gdbs which don't report library events,
but at least we tried.

in theory, we should support fsf gdb on apple now.
this also cleans and documents some execution paths.