bug#3845: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Dmitry Dzhus <dima@sphinx.net.ru>]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

Herbert Euler wrote:

>> > I tried M-x gdb to run emacs under gdb.  The command line was
>> >
>> >   gdb -i=mi ~/src/emacs/src/emacs
>> >
>> > and I got the error '(json-object-format ":" 44).  Here is the backtrace:
>>
>> I could reproduce your problem and I wrote a workaround which fixes the
>> bug for me. Could you please try the attached patch for gdb-mi.el?
>
> That patch works for me, too.  Thanks.

It's in the trunk now.

> 2. The command "shell" is broken: In M-x gdb,
>
>      shell ps aux | grep emacs
>
> results in no output; but in a "real" gdb, the output looks like this:
>
>      shell ps aux | grep emacs
>      &"shell ps aux | grep emacs\n"
>      xgp   4886  1.3  0.1 80796 25900 pts/1   T    09:38   0:08 emacs
>      xgp   4936  0.3  0.1 77688 22568 pts/10  T+   09:39   0:02 ./emacs
>      xgp   5209  0.0  0.1 28128 16548 pts/6   Ss+  09:46   0:00 /usr/local/bin/gdb -i=mi emacs
>      xgp   5353  0.4  0.1 28184 16584 pts/1   S+   09:49   0:00 gdb -i=mi emacs
>      xgp   5354  0.0  0.0 52800  976 pts/1    S+   09:49   0:00 bash -c ps aux | grep emacs
>      xgp   5356  0.0  0.0 51124  688 pts/1    S+   09:49   0:00 grep emacs
>      ^done

Output of GDB's shell command goes as is straight to the terminal
without being prefixed by stream identifier (~, @, & etc.) Thus it's
harder to distinguish where this output should go (to GUD buffer, to MI
parser etc.) I managed to produce a small patch which does the trick for
simple shell commands like yours, but don't expect it to work with
`top(1)` for example. I've attached the patch. Let me know if you notice
that it breaks something.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Print shell command output in GUD buffer --]
[-- Type: text/x-patch, Size: 958 bytes --]

(gdbmi-record-list, gdb-shell): Redirect shell command output to GUD
buffer (Emacs bug #3794)

diff -r 3ba511c84066 gdb-mi.el
--- a/gdb-mi.el
+++ b/gdb-mi.el
@@ -1418,7 +1418,8 @@
     (gdb-stopped . "\\*stopped,?\\(.*?\n\\)")
     (gdb-running . "\\*running,\\(.*?\n\\)")
     (gdb-thread-created . "=thread-created,\\(.*?\n\\)")
-    (gdb-thread-exited . "=thread-exited,\\(.*?\n\\)")))
+    (gdb-thread-exited . "=thread-exited,\\(.*?\n\\)")
+    (gdb-shell . "\\(\\(?:^.+\n\\)+\\)")))
 
 (defun gud-gdbmi-marker-filter (string)
   "Filter GDB/MI output."
@@ -1476,7 +1477,10 @@
     gdb-filter-output))
 
 (defun gdb-gdb (output-field))
-
+(defun gdb-shell (output-field)
+  (let ((gdb-output-sink gdb-output-sink))
+    (setq gdb-filter-output
+          (concat output-field gdb-filter-output))))
 ;; gdb-invalidate-threads is defined to accept 'update-threads signal
 (defun gdb-thread-created (output-field))
 (defun gdb-thread-exited (output-field)

[-- Attachment #3: Type: text/plain, Size: 258 bytes --]


> 3. Previously, typing directly RET at the M-x gdb prompt repeats the
> last command in history. This is also what a "real" gdb does. But in
> the new implementation, this does nothing now.

I've fixed the code which mimicks RET behaviour for GUD buffer.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Repeat last command on RET properly --]
[-- Type: text/x-patch, Size: 507 bytes --]

(gdb-send): Repeat last command on RET properly (Emacs bug #3794).

diff -r b45e93199252 gdb-mi.el
--- a/gdb-mi.el
+++ b/gdb-mi.el
@@ -1267,7 +1267,7 @@
     (let ((inhibit-read-only t))
       (remove-text-properties (point-min) (point-max) '(face))))
   ;; mimic <RET> key to repeat previous command in GDB
-  (if (not (string-match "^\\s+$" string))
+  (if (not (string= "" string))
       (setq gdb-last-command string)
     (if gdb-last-command (setq string gdb-last-command)))
   (if gdb-enable-debug

[-- Attachment #5: Type: text/plain, Size: 545 bytes --]


> As Nick said, this implementation is still in developing.  Should I
> wait then?

It's GSoC project, see http://emacswiki.org/emacs/GDB-MI/ for some
details. Don't wait, report bugs of Emacs trunk version as soon as you
encounter them, but _please_ file *different* reports for different
bugs.

I first put really bleeding changes to my Mercurial repo, then commit
them to Emacs upstream for further testing. Non-stop debugging support
will hit the trunk by the end of this week.
-- 
Happy Hacking.

http://sphinx.net.ru
む