From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77153 invoked by alias); 28 Jul 2019 22:13:55 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 77145 invoked by uid 89); 28 Jul 2019 22:13:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.4 required=5.0 tests=AWL,BAYES_20,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=H*F:D*be, H*r:TLS1.0, fortunately, investigations X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 28 Jul 2019 22:13:51 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34435) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hrrQL-0007cp-HZ for gdb@sourceware.org; Sun, 28 Jul 2019 18:13:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44642) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hrrQL-0002Oj-3C for gdb@gnu.org; Sun, 28 Jul 2019 18:13:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hrrQJ-0007c6-QQ for gdb@gnu.org; Sun, 28 Jul 2019 18:13:49 -0400 Received: from mailsec119.isp.belgacom.be ([195.238.20.115]:28792) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hrrQJ-0007ao-9l for gdb@gnu.org; Sun, 28 Jul 2019 18:13:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1564352027; x=1595888027; h=message-id:subject:from:to:date:in-reply-to:references: mime-version:content-transfer-encoding; bh=bFH/6bp2jJvrfrF0vP0UrIa0nVzzegX3wVx9m3jZbbE=; b=Six6oxAEg0hOGQGQysEsO3uqKCs9N19hLe/4xOlDSNaopv+kAQY7yGez 3BswLpN2KrUBoCchonTVNgHpS+zkew==; Received: from 96.218-128-109.adsl-dyn.isp.belgacom.be (HELO md) ([109.128.218.96]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 29 Jul 2019 00:13:43 +0200 Message-ID: <1564352023.1435.1.camel@skynet.be> Subject: Re: using pipe with command From: Philippe Waroquiers To: Christof Warlich , gdb@gnu.org Date: Sun, 28 Jul 2019 22:13:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 195.238.20.115 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00022.txt.bz2 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 >
, 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 >
, call_site=0x7ffff7801b97 <__libc_start_main+231>) at > src/main.c:54 > 54    } > (gdb) !cat xxx > #0  __cyg_profile_func_enter (func_address=0x41df5d
, > 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 >
, 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 > > > >