gdb mode with gdb command from the docker

gdb mode with gdb command from the docker

[William Xu]

Hi,

I'm trying to use gdb mode with the gdb command from the docker image.
So i defined a wrapper of gdb from docker:

---------------------------------8<-------------------------------------        
#!/bin/sh
arg="$@"
docker exec -i myproject gdb -i=mi ${arg}
---------------------------------8<-------------------------------------

Then invoke the gdb with: (gdb "/path/gdbWrapper").  The *gud* buffer
can be created successfully. The executable file can be loaded OK,
however,  it reports some tty error while trying to run the executable: 

---------------------------------8<------------------------------------- 
(gdb) file a.out
Load new symbol table from "a.out"? (y or n) [answered Y; input not from terminal]
Reading symbols from a.out...done.
(gdb) r
Starting program: /test/a.out 
/dev/ttys002: No such file or directory.
During startup program exited with code 1.
(gdb) 
---------------------------------8<------------------------------------- 

If I run the gdbWrapper directly from a terminal application,
everything is fine, i don't see the same error there.  What could be
wrong in the gdb mode? 

-- 
William

Re: gdb mode with gdb command from the docker

[Eli Zaretskii]

> From: William Xu <william.xwl@gmail.com>
> Date: Sun, 18 Oct 2020 17:08:36 +0200
> 
> Then invoke the gdb with: (gdb "/path/gdbWrapper").  The *gud* buffer
> can be created successfully. The executable file can be loaded OK,
> however,  it reports some tty error while trying to run the executable: 
> 
> ---------------------------------8<------------------------------------- 
> (gdb) file a.out
> Load new symbol table from "a.out"? (y or n) [answered Y; input not from terminal]

This is normal.

> Reading symbols from a.out...done.
> (gdb) r
> Starting program: /test/a.out 
> /dev/ttys002: No such file or directory.

This is not, but the error message seems to come from a.out, not from
GDB.  So I think you should review the program's code and see why it
fails that way.

Re: gdb mode with gdb command from the docker

[William Xu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: William Xu <william.xwl@gmail.com>
>> Date: Sun, 18 Oct 2020 17:08:36 +0200
>> 
>> Then invoke the gdb with: (gdb "/path/gdbWrapper").  The *gud* buffer
>> can be created successfully. The executable file can be loaded OK,
>> however,  it reports some tty error while trying to run the executable: 
>> 
>> ---------------------------------8<------------------------------------- 
>> (gdb) file a.out
>> Load new symbol table from "a.out"? (y or n) [answered Y; input not from terminal]
>
> This is normal.
>
>> Reading symbols from a.out...done.
>> (gdb) r
>> Starting program: /test/a.out 
>> /dev/ttys002: No such file or directory.
>
> This is not, but the error message seems to come from a.out, not from
> GDB.  So I think you should review the program's code and see why it
> fails that way.

Hmm, I saw similar error in my original executable, in the created test
program,  it only prints a string:

#include <iostream>
int main()
{
	std::cout << "hi" << std::endl;
}

Also as I mentioned, if I run the gdbWrapper directly outside emacs, on
the terminal app (i'm running Terminal on macOS), there is no problem
seen at all . I think it is more likely something wrong inside emacs's
gdb mode. (I tested it also with `emacs -Q',  same error)

-- 
William

Re: gdb mode with gdb command from the docker

[Eli Zaretskii]

> From: William Xu <william.xwl@gmail.com>
> Date: Sun, 18 Oct 2020 20:18:22 +0200
> 
> >> (gdb) r
> >> Starting program: /test/a.out 
> >> /dev/ttys002: No such file or directory.
> >
> > This is not, but the error message seems to come from a.out, not from
> > GDB.  So I think you should review the program's code and see why it
> > fails that way.
> 
> Hmm, I saw similar error in my original executable, in the created test
> program,  it only prints a string:

The error message could come from some library function.

> Also as I mentioned, if I run the gdbWrapper directly outside emacs, on
> the terminal app (i'm running Terminal on macOS), there is no problem
> seen at all.

Of course: when the program is run from GDB under Emacs, the standard
output and standard input of the program are connected to a PTY
(pseudo-terminal), not to a real console device.  So it is a small
wonder that the behavior is different.

> I think it is more likely something wrong inside emacs's
> gdb mode.

Maybe so, but I don't see what would cause this in gdb mode.

Re: gdb mode with gdb command from the docker

[William Xu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Also as I mentioned, if I run the gdbWrapper directly outside emacs, on
>> the terminal app (i'm running Terminal on macOS), there is no problem
>> seen at all.
>
> Of course: when the program is run from GDB under Emacs, the standard
> output and standard input of the program are connected to a PTY
> (pseudo-terminal), not to a real console device.  So it is a small
> wonder that the behavior is different.
>
>> I think it is more likely something wrong inside emacs's
>> gdb mode.
>
> Maybe so, but I don't see what would cause this in gdb mode.

I manage to make it work by disabling the gdb "-inferior-tty-set"
command in gdb-inferior-io--init-proc.

It seems that the problem is that, process.c::allocate_pty allocates a
pseudo-terminal for the *host*, I can find the same tty name in /dev on
the host. It then confuses the gdb command from the docker container.

Is there any reason to call "-inferior-tty-set" commands here? Can we
simply remove it? 

---------------------------------8<-------------------------------------
 $ git diff
diff --git a/lisp/progmodes/gdb-mi.el b/lisp/progmodes/gdb-mi.el
index e785acd284..63dae4b248 100644
--- a/lisp/progmodes/gdb-mi.el
+++ b/lisp/progmodes/gdb-mi.el
@@ -1590,12 +1590,13 @@ gdb-inferior-io--init-proc
   (set-process-filter proc 'gdb-inferior-filter)
   (set-process-sentinel proc 'gdb-inferior-io-sentinel)
   ;; The process can run on a remote host.
-  (let ((tty (or (process-get proc 'remote-tty)
-                (process-tty-name proc))))
-    (unless (or (null tty)
-               (string= tty ""))
-      (gdb-input
-       (concat "-inferior-tty-set " tty) 'ignore))))
+  ;; (let ((tty (or (process-get proc 'remote-tty)
+  ;;            (process-tty-name proc))))
+  ;;   (unless (or (null tty)
+  ;;           (string= tty ""))
+  ;;     (gdb-input
+  ;;      (concat "-inferior-tty-set " tty) 'ignore)))
+  )
 
 (defun gdb-inferior-io-sentinel (proc _str)
   (when (eq (process-status proc) 'failed)
---------------------------------8<-------------------------------------

-- 
William

Re: gdb mode with gdb command from the docker

[Eli Zaretskii]

> From: William Xu <william.xwl@gmail.com>
> Date: Tue, 20 Oct 2020 21:54:55 +0200
> 
> I manage to make it work by disabling the gdb "-inferior-tty-set"
> command in gdb-inferior-io--init-proc.
> 
> It seems that the problem is that, process.c::allocate_pty allocates a
> pseudo-terminal for the *host*, I can find the same tty name in /dev on
> the host. It then confuses the gdb command from the docker container.
> 
> Is there any reason to call "-inferior-tty-set" commands here? Can we
> simply remove it? 

No, this setting is needed to separate the I/O device of the process
being debugged from that of GDB, so that we could redirect I/O of the
debuggee to a dedicated buffer used by "M-x gdb" to show interaction
with the program.

Re: gdb mode with gdb command from the docker

[William Xu]

Eli Zaretskii <eliz@gnu.org> writes:

> No, this setting is needed to separate the I/O device of the process
> being debugged from that of GDB, so that we could redirect I/O of the
> debuggee to a dedicated buffer used by "M-x gdb" to show interaction
> with the program.

Can we at least add an option to disable the I/O separation, like
gdb-disable-io-redirection? So that one can still have a working gdb,
even if the I/O are mixed with gdb commands. So that I would still have
the nice features of gdb modes, with which I can set breakpoints, follow
line by line in the source buffer. That is already a huge improvement on
the plain terminal gdb.

In addition, I just noticed that tramp seems supporting such kind of
remote debugging, from [[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>
`----

Only that when trying it out with ssh method, I got an error after the
file is loaded. Should I report a bug for it?

---------------------------------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<-------------------------------------

-- 
William

Re: gdb mode with gdb command from the docker

[Eli Zaretskii]

> From: William Xu <william.xwl@gmail.com>
> Date: Thu, 22 Oct 2020 20:41:52 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, this setting is needed to separate the I/O device of the process
> > being debugged from that of GDB, so that we could redirect I/O of the
> > debuggee to a dedicated buffer used by "M-x gdb" to show interaction
> > with the program.
> 
> Can we at least add an option to disable the I/O separation, like
> gdb-disable-io-redirection? So that one can still have a working gdb,
> even if the I/O are mixed with gdb commands. So that I would still have
> the nice features of gdb modes, with which I can set breakpoints, follow
> line by line in the source buffer. That is already a huge improvement on
> the plain terminal gdb.

I don't understand why you need this.  Didn't you say that the problem
disappears if you use Yuri's advice?  Then why do we need any kludgey
changes in gdb-mi.el?

> In addition, I just noticed that tramp seems supporting such kind of
> remote debugging, from [[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>
> `----
> 
> Only that when trying it out with ssh method, I got an error after the
> file is loaded. Should I report a bug for it?

Yes, please.

Re: gdb mode with gdb command from the docker

[William Xu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand why you need this.  Didn't you say that the problem
> disappears if you use Yuri's advice?  Then why do we need any kludgey
> changes in gdb-mi.el?

Sorry for the confusion. I thought that was only for
verification/comparsion purpose, as running in the shell by "M-x shell"
is more or less the same as running it from terminal app. I won't have
all the nice features of gdb-mi.el.

But it looks like tramp remote debug is the better way to go. I will see
if we can have it working with tramp.

Thanks for the help. 

>> Only that when trying it out with ssh method, I got an error after the
>> file is loaded. Should I report a bug for it?
>
> Yes, please.

Done. 

-- 
William

Re: gdb mode with gdb command from the docker

[Yuri Khan]

On Sun, 18 Oct 2020 at 18:08, William Xu <william.xwl@gmail.com> wrote:

> I'm trying to use gdb mode with the gdb command from the docker image.
> So i defined a wrapper of gdb from docker:
>
> ---------------------------------8<-------------------------------------
> #!/bin/sh
> arg="$@"
> docker exec -i myproject gdb -i=mi ${arg}
> ---------------------------------8<-------------------------------------
>
> Then invoke the gdb with: (gdb "/path/gdbWrapper").  The *gud* buffer
> can be created successfully. The executable file can be loaded OK,
> however,  it reports some tty error while trying to run the executable:

Does giving the -t option to ‘docker exec’ help in any way? (I did not
test this; just a hunch because something seems to expect a tty and -t
causes docker to allocate one.)

Re: gdb mode with gdb command from the docker

[otadmor]

As gud is great and all, not always you need all of its capabilities.
Does running gdb from shell (M-x shell) works?

On Sun, Oct 18, 2020, 21:49 Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Sun, 18 Oct 2020 at 18:08, William Xu <william.xwl@gmail.com> wrote:
>
> > I'm trying to use gdb mode with the gdb command from the docker image.
> > So i defined a wrapper of gdb from docker:
> >
> > ---------------------------------8<-------------------------------------
> > #!/bin/sh
> > arg="$@"
> > docker exec -i myproject gdb -i=mi ${arg}
> > ---------------------------------8<-------------------------------------
> >
> > Then invoke the gdb with: (gdb "/path/gdbWrapper").  The *gud* buffer
> > can be created successfully. The executable file can be loaded OK,
> > however,  it reports some tty error while trying to run the executable:
>
> Does giving the -t option to ‘docker exec’ help in any way? (I did not
> test this; just a hunch because something seems to expect a tty and -t
> causes docker to allocate one.)
>
>

Re: gdb mode with gdb command from the docker

[William Xu]

otadmor <otadmor@gmail.com> writes:

> As gud is great and all, not always you need all of its capabilities.
> Does running gdb from shell (M-x shell) works?

Yes,  it also works flawlessly there. 

-- 
William

Re: gdb mode with gdb command from the docker

[William Xu]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Sun, 18 Oct 2020 at 18:08, William Xu <william.xwl@gmail.com> wrote:
>
>> I'm trying to use gdb mode with the gdb command from the docker image.
>> So i defined a wrapper of gdb from docker:
>>
>> ---------------------------------8<-------------------------------------
>> #!/bin/sh
>> arg="$@"
>> docker exec -i myproject gdb -i=mi ${arg}
>> ---------------------------------8<-------------------------------------
>>
>> Then invoke the gdb with: (gdb "/path/gdbWrapper").  The *gud* buffer
>> can be created successfully. The executable file can be loaded OK,
>> however,  it reports some tty error while trying to run the executable:
>
> Does giving the -t option to ‘docker exec’ help in any way? (I did not
> test this; just a hunch because something seems to expect a tty and -t
> causes docker to allocate one.)

I tried that earlier (changed it to: docker exec -it ... ), it seems making the situation worse, : )

Beside the same error showing up when running it,  I also found this new
error at the beginning of the buffer: 

Error: you did not specify -i=mi on GDB's command line!

-- 
William