bug-gnu-emacs
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]