From: Marc Khouzam <marc.khouzam@ericsson.com>
To: 'Tom Tromey' <tromey@redhat.com>
Cc: 'Yao Qi' <yao@codesourcery.com>,
"'gdb-patches@sourceware.org'" <gdb-patches@sourceware.org>,
'Pedro Alves' <palves@redhat.com>,
"'Joel Brobecker'" <brobecker@adacore.com>,
'Stan Shebs' <stanshebs@earthlink.net>
Subject: RE: DPrintf feedback
Date: Fri, 22 Feb 2013 20:37:00 -0000 [thread overview]
Message-ID: <E59706EF8DB1D147B15BECA3322E4BDC0C3DD0@eusaamb103.ericsson.se> (raw)
In-Reply-To: <87fw0o87r4.fsf@fleche.redhat.com>
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Friday, February 22, 2013 2:32 PM
> To: Marc Khouzam
> Cc: 'Yao Qi'; 'gdb-patches@sourceware.org'; 'Pedro Alves';
> 'Joel Brobecker'; 'Stan Shebs'
> Subject: Re: DPrintf feedback
>
> >>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:
>
> Marc> Such an approach may also help fix the "continue" problem
> Marc> that Yao is trying to address. I seem to recall that
> Hui had posted
> Marc> patches to add some kind of 'printf' tracepoint
> command. Maybe that
> Marc> would be something that can help?
>
> 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
command be "agent-printf <string>".
I didn't expect that to be something that could be re-used
by a tracepoint command. But that makes me realize the
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
> opening PRs was
> Marc> the way to do since those issues may disappear if the current
> Marc> implementation is amended:
>
> I think it is best to file PRs. If a patch fixes them all,
> 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'.
>
> Maybe we need a new "gdb-unfiltered" setting? Or we could disable
> pagination entirely here, but that maybe leads to other issues.
>
> Marc> - In Eclipse, the dprintf-style that makes sense is either
> Marc> 'call' or 'agent'.
>
> 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
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
> Marc> example, if my program does
> Marc> printf("hello");
> Marc> printf("friend\n");
> Marc> and I put a dprintf " my " on the second line,
> 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
> Marc> buffer as the real printfs, and is flushed earlier.
> Marc> This also happens with the dprintf-style "agent"
>
> 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
next prev parent reply other threads:[~2013-02-22 20:37 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-18 13:09 [RFC] PR 15075 dprintf interferes with "next" Yao Qi
2013-02-18 21:36 ` Joel Brobecker
2013-02-21 16:36 ` Tom Tromey
2013-04-24 1:24 ` Hui Zhu
2013-04-24 6:06 ` Keith Seitz
2013-04-24 13:30 ` Hui Zhu
2013-04-24 14:03 ` Yao Qi
2013-04-24 14:09 ` Hui Zhu
2013-05-16 7:29 ` Hui Zhu
2013-05-17 21:01 ` Pedro Alves
2013-05-22 10:22 ` Hui Zhu
2013-05-22 12:46 ` Pedro Alves
2013-05-28 0:02 ` Hui Zhu
2013-05-28 3:36 ` Yao Qi
2013-05-29 10:08 ` Hui Zhu
2013-06-03 4:07 ` Hui Zhu
2013-06-03 17:48 ` Pedro Alves
2013-06-07 3:16 ` Hui Zhu
2013-06-17 7:36 ` Hui Zhu
2013-06-18 18:16 ` Pedro Alves
2013-06-24 8:36 ` Hui Zhu
2013-06-24 22:06 ` Pedro Alves
2013-06-25 9:14 ` Hui Zhu
2013-06-25 11:47 ` Pedro Alves
2013-06-25 13:02 ` Hui Zhu
2013-06-25 14:06 ` Pedro Alves
2013-06-26 2:54 ` Hui Zhu
2013-05-22 14:04 ` Tom Tromey
2013-02-22 17:39 ` DPrintf feedback (was: [RFC] PR 15075 dprintf interferes with "next") Marc Khouzam
2013-02-22 19:32 ` DPrintf feedback Tom Tromey
2013-02-22 20:37 ` Marc Khouzam [this message]
2013-02-26 21:12 ` Marc Khouzam
2013-02-28 15:32 ` [PATCH 1/4] Fix dprintf bugs Yao Qi
2013-02-28 13:17 ` [PATCH 3/4] Test dprintf breakpoint works correctly with other breakpoints Yao Qi
2013-02-28 13:17 ` [PATCH 2/4] Test case of conditional dprintf Yao Qi
2013-02-28 14:48 ` [PATCH 4/4] Test case on setting dprintf commands Yao Qi
2013-02-28 16:30 ` [PATCH 1/4] Fix dprintf bugs Eli Zaretskii
2013-03-07 7:45 ` Yao Qi
2013-03-03 2:21 ` Marc Khouzam
2013-03-07 6:47 ` Yao Qi
2013-03-07 14:06 ` Marc Khouzam
2013-03-07 14:36 ` Yao Qi
2013-03-07 14:49 ` Marc Khouzam
2013-03-07 14:59 ` Yao Qi
2013-03-08 15:49 ` Marc Khouzam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E59706EF8DB1D147B15BECA3322E4BDC0C3DD0@eusaamb103.ericsson.se \
--to=marc.khouzam@ericsson.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=stanshebs@earthlink.net \
--cc=tromey@redhat.com \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox