using pipe with command

using pipe with command

[Christof Warlich]

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

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

Re: using pipe with command

[Christof Warlich]

Am 29.07.19 um 00:13 schrieb Philippe Waroquiers:

> 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
Many thanks for looking into this issue. I'm definitely not of much use
w.r.t. some decent suggestions but I'd be glad if I could help otherwise.

Re: using pipe with command

[Philippe Waroquiers]

On Mon, 2019-07-29 at 21:32 +0200, Christof Warlich wrote:
> Am 29.07.19 um 00:13 schrieb Philippe Waroquiers:
> 
> > 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
> Many thanks for looking into this issue. I'm definitely not of much use
> w.r.t. some decent suggestions but I'd be glad if I could help otherwise.
As far as I can see, this is fixed in recent git master.
Not too sure what fixed the problem, maybe a side effect of:
65d1cd5f9cbcbb2df0b187cb7623949c1668728f
[gdb] Only force INTERP_CONSOLE ui_out for breakpoint commands in MI mode

Philippe

Re: using pipe with command

[Christof Warlich]

Am 23.11.19 um 15:19 schrieb Philippe Waroquiers:

> On Mon, 2019-07-29 at 21:32 +0200, Christof Warlich wrote:
>> Am 29.07.19 um 00:13 schrieb Philippe Waroquiers:
>>
>>> 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
>> Many thanks for looking into this issue. I'm definitely not of much use
>> w.r.t. some decent suggestions but I'd be glad if I could help otherwise.
> As far as I can see, this is fixed in recent git master.
Thanks for the update.
> Not too sure what fixed the problem, maybe a side effect of:
> 65d1cd5f9cbcbb2df0b187cb7623949c1668728f
> [gdb] Only force INTERP_CONSOLE ui_out for breakpoint commands in MI mode

Yes, I can confirm your guess: The issue remains to be seen until commit
65d1cd5f9cbcbb2df0b187cb7623949c1668728 and vanishes with that very
commit :-).

Cheers,

Chris