[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62697: gdb-mi.el: Change target-async to mi-async
From: |
Eli Zaretskii |
Subject: |
bug#62697: gdb-mi.el: Change target-async to mi-async |
Date: |
Fri, 07 Apr 2023 13:53:59 +0300 |
> From: Gustaf Waldemarson <gustaf.waldemarson@gmail.com>
> Date: Fri, 7 Apr 2023 12:36:31 +0200
> Cc: Jim Porter <jporterbugs@gmail.com>, 62697@debbugs.gnu.org
>
> Filtering the message is probably easy, but as Jim pointed out, it will
> probably
> have unintended consequences later on.
Leave that problem to me (or to the maintainer that will come after
me). The problem you raised was with the annoying message; let's
solve that first and foremost.
> Besides, extracting the version could
> enable a lot of different things down the line.
It could, but it is "tricky", as you have discovered (and I discovered
before you).
> I had actually started on a "check-gdb-version-string", but was never able to
> get it to work. In fact, revisiting that code now makes we wonder if any of
> these
> "handlers" are actually working as intended.
They do work. It's just that the way this is implemented is "tricky",
as I said from the get-go.
> From what I can see, the handlers scan the current buffer (which one is that
> anyways?)
> to determine whether to do some operations. However, adding some prints to
> these handlers reveal that they seem to always be empty:
>
> (defun gdb-non-stop-handler ()
> (goto-char (point-min))
> (print (buffer-substring-no-properties (point-min) (point-max)))
> (if (re-search-forward "No symbol" nil t)
> (progn
> (message
> "This version of GDB doesn't support non-stop mode. Turning it
> off.")
> (setq gdb-non-stop nil)
> (setq gdb-supports-non-stop nil))
> (setq gdb-supports-non-stop t)
> (gdb-input "-gdb-set mi-async on" 'ignore)
> (gdb-input "-list-target-features" 'gdb-check-mi-async)))
The "No symbol" text means that we have invoked a command that is not
supported by the GDB you have installed. Unless you test this with a
very old version of GDB, you will never see that text.
The way these commands work is like this:
. gdb-input sends a command which has a serial number (the numbers
are allocated by gdb-mi.el in increasing order, starting from 1)
. gdb-input also registers a callback for the response
. when the response is received, it is recognized by the serial
number (GDB responds with the same serial number as the command to
which it responded), and the corresponding callback is then
called, and removed from the list of callbacks waiting for
response
. each callback is programmed to look for possible known GDB
reactions (per the GDB/MI protocol), which could be one or more
of:
- nothing (a normal reaction in many cases)
- some output, like if the command requests the list of threads
- an error message
- free text message
. these texts are (AFAIR) looked for in the process buffer, where
the filter puts them