From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4406 invoked by alias); 22 Feb 2013 20:37:47 -0000 Received: (qmail 4108 invoked by uid 22791); 22 Feb 2013 20:37:45 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Feb 2013 20:37:35 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 99.C4.03705.E07D7215; Fri, 22 Feb 2013 21:37:34 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 15:37:33 -0500 From: Marc Khouzam To: 'Tom Tromey' CC: 'Yao Qi' , "'gdb-patches@sourceware.org'" , 'Pedro Alves' , "'Joel Brobecker'" , 'Stan Shebs' Subject: RE: DPrintf feedback Date: Fri, 22 Feb 2013 20:37:00 -0000 Message-ID: References: <1361192891-29341-1-git-send-email-yao@codesourcery.com> <87fw0o87r4.fsf@fleche.redhat.com> In-Reply-To: <87fw0o87r4.fsf@fleche.redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00604.txt.bz2 > -----Original Message----- > From: Tom Tromey [mailto:tromey@redhat.com]=20 > Sent: Friday, February 22, 2013 2:32 PM > To: Marc Khouzam > Cc: 'Yao Qi'; 'gdb-patches@sourceware.org'; 'Pedro Alves';=20 > 'Joel Brobecker'; 'Stan Shebs' > Subject: Re: DPrintf feedback >=20 > >>>>> "Marc" =3D=3D Marc Khouzam writes: >=20 > Marc> Such an approach may also help fix the "continue" problem > Marc> that Yao is trying to address. I seem to recall that=20 > Hui had posted=20 > Marc> patches to add some kind of 'printf' tracepoint=20 > command. Maybe that=20 > Marc> would be something that can help? >=20 > I thought this was subsumed by "set dprintf-style agent"? I haven't followed the details, so I can't be sure. "set dprintf-style agent" makes the dprintf breakpoint=20 command be "agent-printf ". I didn't expect that to be something that could be re-used by a tracepoint command. But that makes me realize the=20 bigger limitation of using tracepoints; tracepoints are only supported with gdbserver. I thought a tracepoint doing the printf would be nice for each case, not just with gdbserver. I guess there's a lot more work needed to first support tracepoints in GDB alone, and then use them for dprintf. I missed that detail. I wonder if you guys feel tracepoints would be a nicer way to handle dprintf? > Marc> Other issues I ran across are below. I wasn't sure=20 > opening PRs was > Marc> the way to do since those issues may disappear if the current=20 > Marc> implementation is amended: >=20 > I think it is best to file PRs. If a patch fixes them all,=20 > then that is > fine. But if not, then this the only way to avoid losing track. Will do. > Marc> - Pagination is triggered for dprintf in CLI mode, at least when > Marc> using dprintf-style 'gdb'. >=20 > Maybe we need a new "gdb-unfiltered" setting? Or we could disable > pagination entirely here, but that maybe leads to other issues. >=20 > Marc> - In Eclipse, the dprintf-style that makes sense is either=20 > Marc> 'call' or 'agent'. >=20 > I was surprised to hear this. Could you say why? On Linux, Eclipse uses the -inferior-tty-set command to tell GDB to send the inferior's output to a different console. So we have a gdb console and an inferior console. If we want dprintf to look=20 like a real printf, its output needs to be shown in the inferior console, so it requires GDB to send it to the same tty. That is not what "dprintf-style gdb" does, as it sends it to the gdb console. > Marc> - Output buffering is not behaving as a real printf. For=20 > Marc> example, if my program does > Marc> printf("hello"); > Marc> printf("friend\n"); > Marc> and I put a dprintf " my " on the second line,=20 > Marc> I would expect to see > Marc> "hello my friend" > Marc> but instead I see > Marc> " my hellofriend" > Marc> which shows that the dprintf string does not go to the same=20 > Marc> buffer as the real printfs, and is flushed earlier. > Marc> This also happens with the dprintf-style "agent" >=20 > Which other setting does this happen with? > I would expect it to work with "call" but not with "gdb". > > You could hack around this by disabling buffering for stdout. > I'm not totally sure it is a bug for it to work the current way by > default. I hadn't tried it with "call" because my machine is an Ubuntu, so the "call" setting does not work. I managed to get my hands on a Suse machine and tried it; you are right, "call" prints things nicely. I guess the problem is only that "agent" style does not do that properly. I'll specify this important point in the PR. Thanks for the quick answer. Marc