using pipe with command

[Philippe Waroquiers]

Some investigations shows that the problem is linked
to "tui" and the gdb observer pattern and user defined commands.

Most commands (such as "bt") are directly producing their output.
Some commands (such as "up", "thread" switch) are producing some
output using an observer pattern.  Their output is then
produced by functions tui_on_user_selected_context_changed
(if tui is configured) or cli_on_user_selected_context_changed
(if tui is not configured) or mi_user_selected_context_changed
(if mi is used).


At least tui_on_user_selected_context_changed is not
properly handling the redirection
of GDB output: the output still goes to stdout, instead of
being redirected.

This 'redirect' bug is not limited to the 'pipe' command.
For example, the below shows that the python gdb.execute
third argument (telling to produce the output in a string) is
equally broken when calling the "up" command: the first 2 calls
shows that "bt" output correctly goes to a string when the third
argument is True, but for the "up" command, the output always
goes to GDB stdout.

I have not (yet) understood how GDB handles stdout
redirection when tui is enabled, and so I have no idea yet how
to fix that.

Redirecting to a string or to a file/pipe probably should also
redirect tui_old_uiout.
Or possibly tui_on_user_selected_context_changed should do
some redirections like mi_user_selected_context_changed ?

Suggestions welcome :)

Philippe

(gdb) python gdb.execute("bt", True, True)
(gdb) python gdb.execute("bt", True, False)
#0Â Â 0x00007ffff78fe603 in select () at ../sysdeps/unix/syscall-template.S:84
#1Â Â 0x0000555555554f5e in sleeper_or_burner (v=0x7fffffffdf30) at sleepers.c:86
#2Â Â 0x000055555555549d in main (argc=1, argv=0x7fffffffe0b8) at sleepers.c:194
(gdb) python gdb.execute("up", True, True)
#1Â Â 0x0000555555554f5e in sleeper_or_burner (v=0x7fffffffdf30) at sleepers.c:86
86	Â Â Â Â Â Â Â Â Â ret = select (0, NULL, NULL, NULL, &t[s->t]);
(gdb) python gdb.execute("up", True, False)
#2Â Â 0x000055555555549d in main (argc=1, argv=0x7fffffffe0b8) at sleepers.c:194
194	Â Â sleeper_or_burner(&m);
(gdb)Â 


On Mon, 2019-07-15 at 22:35 +0200, Christof Warlich wrote:
> Hi,
> 
> I just got quite exited when I saw the newly introduced "pipe" command.
> But a closer look reveals that it does somewhat only work
> "occasionally". Fortunately, "occasionally" here means that the issue is
> at least reproducible. Here are some examples that show the problem.
> Note that the code (of GNU make) that I'm using is compiled with "-f 
> instrument-function" with appropriate function definitions. But I'd
> assume that the issue occurs with any code being debugged.
> 
> In the following example, file "xxx" remains empty, although it should
> contain the output of the "up" command:
> 
>     ...
>     Reading symbols from make...
>     (gdb) b __cyg_profile_func_enter
>     Breakpoint 1 at 0x41d6d5: file src/main.c, line 54.
>     (gdb) command 1
>     Type commands for breakpoint(s) 1, one per line.
>     End with a line saying just "end".
>      >pipe up | cat - >xxx
>      >end
>     (gdb) run
>     Starting program: /home/christof/Local/Repos/make/make
> 
>     Breakpoint 1, __cyg_profile_func_enter (func_address=0x41df5d
>     <main>, call_site=0x7ffff7801b97 <__libc_start_main+231>) at
>     src/main.c:54
>     54Â Â Â  }
>     #1Â  0x000000000041dfa1 in main (argc=1, argv=0x7fffffffe0c8,
>     envp=0x7fffffffe0d8) at src/main.c:1074
>     1074Â Â Â  {
>     (gdb) !cat xxx
>     (gdb)
> 
> Strange enough, almost the same setup works when replacing the "up"
> command with the "bt" command: File xxx contains a backtrace as expected.
> 
>     ...
>     Reading symbols from make...
>     (gdb) b __cyg_profile_func_enter
>     Breakpoint 1 at 0x41d6d5: file src/main.c, line 54.
>     (gdb) command 1
>     Type commands for breakpoint(s) 1, one per line.
>     End with a line saying just "end".
>      >pipe bt | cat - >xxx
>      >end
>     (gdb) run
>     Starting program: /home/christof/Local/Repos/make/make
> 
>     Breakpoint 1, __cyg_profile_func_enter (func_address=0x41df5d
>     <main>, call_site=0x7ffff7801b97 <__libc_start_main+231>) at
>     src/main.c:54
>     54Â Â Â  }
>     (gdb) !cat xxx
>     #0Â  __cyg_profile_func_enter (func_address=0x41df5d <main>,
>     call_site=0x7ffff7801b97 <__libc_start_main+231>) at src/main.c:54
>     #1Â  0x000000000041dfa1 in main (argc=1, argv=0x7fffffffe0c8,
>     envp=0x7fffffffe0d8) at src/main.c:1074
>     (gdb)
> 
> 
> To make things even more weird, piping the output of the "up" command
> directly (i.e. outside of the "command" command) works as well as expected:
> 
>     ...
>     Reading symbols from make...
>     (gdb) b __cyg_profile_func_enter
>     Breakpoint 1 at 0x41d6d5: file src/main.c, line 54.
>     (gdb) run
>     Starting program: /home/christof/Local/Repos/make/make
> 
>     Breakpoint 1, __cyg_profile_func_enter (func_address=0x41df5d
>     <main>, call_site=0x7ffff7801b97 <__libc_start_main+231>) at
>     src/main.c:54
>     54Â Â Â  }
>     (gdb) pipe up | cat - >xxx
>     (gdb) !cat xxx
>     #1Â  0x000000000041dfa1 in main (argc=1, argv=0x7fffffffe0c8,
>     envp=0x7fffffffe0d8) at src/main.c:1074
>     1074Â Â Â  {
>     (gdb)
> 
> I'm aware that the "pipe" command may still be "in development", but
> maybe this early report may help to fix a lingering issue ... And I
> certainly would be more than happy to test any patch :-).
> 
> Cheers,
> 
> Chris
> 
> 
> 
>