bug#44151: trmap: remote gdb with ssh doesn't work

bug#44151: trmap: remote gdb with ssh doesn't work

[William Xu]

Hi,

I tried to run the debug remote program with gdb via ssh. I followed the
instructions from the [[info:tramp#Remote processes][info:tramp#Remote processes]]:

,----
| 5.5.5 Running a debugger on a remote host
| -----------------------------------------
| 
| ‘gud.el’ provides a unified interface to symbolic debuggers (*note
| (emacs)Debuggers::).  TRAMP can run debug on remote hosts by calling
| ‘gdb’ with a remote file name:
| 
|      M-x gdb <RET>
|      Run gdb (like this): gdb -i=mi /ssh:host:~/myprog <RET>
`----

However, after the program to debug is read, it looks like there is some
error setting up gdb's inferior tty?

---------------------------------8<------------------------------------- 
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/wx/tmp/a.out...

Debugger entered--Lisp error: (wrong-type-argument "consp nil")
  signal(wrong-type-argument ("consp nil"))
  tramp-signal-hook-function(wrong-type-argument (consp nil))
  signal(wrong-type-argument (consp nil))
  tramp-sh-handle-make-process(:name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t)
  apply(tramp-sh-handle-make-process (:name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t))
  tramp-sh-file-name-handler(make-process :name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t)
  apply(tramp-sh-file-name-handler make-process (:name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t))
  tramp-file-name-handler(make-process :name "gdb-inferior" :buffer #<buffer limbo<3>> :command nil :stderr nil :noquery nil :file-handler t)
  tramp-handle-start-file-process("gdb-inferior" #<buffer limbo<3>> nil)
  apply(tramp-handle-start-file-process ("gdb-inferior" #<buffer limbo<3>> nil))
  tramp-sh-file-name-handler(start-file-process "gdb-inferior" #<buffer limbo<3>> nil)
  apply(tramp-sh-file-name-handler start-file-process ("gdb-inferior" #<buffer limbo<3>> nil))
  tramp-file-name-handler(start-file-process "gdb-inferior" #<buffer limbo<3>> nil)
  apply(tramp-file-name-handler start-file-process "gdb-inferior" #<buffer limbo<3>> nil nil)
  start-file-process("gdb-inferior" #<buffer limbo<3>> nil)
  apply(start-file-process "gdb-inferior" #<buffer limbo<3>> nil nil)
  comint-exec-1("gdb-inferior" #<buffer limbo<3>> nil nil)
  comint-exec(#<buffer limbo<3>> "gdb-inferior" nil nil nil)
  make-comint-in-buffer("gdb-inferior" #<buffer limbo<3>> nil)
  gdb-inferior-io-mode()
  gdb-get-buffer-create(gdb-inferior-io)
  gdb-init-1()
  gdb-update()
  gdb("gdb -i=mi /ssh:wx@SERVER:/home/wx/tmp...")
  funcall-interactively(gdb "gdb -i=mi /ssh:wx@SERVER:/home/wx/tmp...")
  call-interactively(gdb record nil)
  command-execute(gdb record)
  execute-extended-command(nil "gdb" nil)
  funcall-interactively(execute-extended-command nil "gdb" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)
---------------------------------8<------------------------------------- 

I tested it with `-Q' by building the latest emacs in the git:

GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6032)) of 2020-10-22

-- 
William

bug#44151: trmap: remote gdb with ssh doesn't work

[Michael Albinus]

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

William Xu <william.xwl@gmail.com> writes:

> Hi,

Hi,

> However, after the program to debug is read, it looks like there is some
> error setting up gdb's inferior tty?
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /home/wx/tmp/a.out...
>
> Debugger entered--Lisp error: (wrong-type-argument "consp nil")
>   signal(wrong-type-argument ("consp nil"))

Confirmed. Does the appended patch fixes the problem?

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 962 bytes --]

*** /tmp/ediffsLfY1u	2020-10-23 16:51:34.788931136 +0200
--- /home/albinus/src/tramp/lisp/tramp-sh.el	2020-10-23 16:46:48.832033338 +0200
***************
*** 2809,2815 ****
  	    (signal 'wrong-type-argument (list #'stringp name)))
  	  (unless (or (null buffer) (bufferp buffer) (stringp buffer))
  	    (signal 'wrong-type-argument (list #'stringp buffer)))
! 	  (unless (consp command)
  	    (signal 'wrong-type-argument (list #'consp command)))
  	  (unless (or (null coding)
  		      (and (symbolp coding) (memq coding coding-system-list))
--- 2809,2815 ----
  	    (signal 'wrong-type-argument (list #'stringp name)))
  	  (unless (or (null buffer) (bufferp buffer) (stringp buffer))
  	    (signal 'wrong-type-argument (list #'stringp buffer)))
! 	  (unless (or (null command) (consp command))
  	    (signal 'wrong-type-argument (list #'consp command)))
  	  (unless (or (null coding)
  		      (and (symbolp coding) (memq coding coding-system-list))

bug#44151: trmap: remote gdb with ssh doesn't work

[William Xu]

Michael Albinus <michael.albinus@gmx.de> writes:

> Confirmed. Does the appended patch fixes the problem?

Thanks for the fast fix! Yes, now gdb can work.

However, I notice that after I set a breakpoint in the file, I could see
the red dot for the breakpoint in the buffer, but when I start to run
it, I don't see the debugger step marker in the file buffer, for
indicating the next line to follow. Is this expected behavior?

-- 
William

bug#44151: trmap: remote gdb with ssh doesn't work

[Michael Albinus]

William Xu <william.xwl@gmail.com> writes:

Hi,

> Thanks for the fast fix! Yes, now gdb can work.

Thanks for the feedback. I've pushed the patch to the repo.

> However, I notice that after I set a breakpoint in the file, I could see
> the red dot for the breakpoint in the buffer, but when I start to run
> it, I don't see the debugger step marker in the file buffer, for
> indicating the next line to follow. Is this expected behavior?

No, I don't believe so. I could confirm this misbehaviour.

And I'm sorry, I don't know gdb-mi.el. Hopefully, somebody else could
fix this.

Best regards, Michael.