From: Tom Tromey <tromey@redhat.com>
To: Hui Zhu <teawater@gmail.com>
Cc: Pedro Alves <palves@redhat.com>, Eli Zaretskii <eliz@gnu.org>,
Hui Zhu <hui_zhu@mentor.com>,
gdb-patches ml <gdb-patches@sourceware.org>,
Marc Khouzam <marc.khouzam@ericsson.com>
Subject: Re: [PATCH] add -s option to make -break-insert support dprintf
Date: Tue, 07 May 2013 20:50:00 -0000 [thread overview]
Message-ID: <87d2t2tt02.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CANFwon3yyKxMVRO3wJ3=VTDLpege_NWByMA9-jk_g9_a5mXaoQ@mail.gmail.com> (Hui Zhu's message of "Fri, 3 May 2013 13:42:53 +0800")
>>>>> "Hui" == Hui Zhu <teawater@gmail.com> writes:
Hui> According to your comments. I did some update with these patches to
Hui> added special command -dprintf-insert to insert dprintf. Its format
Hui> is close to simple dprintf command:
Hui> -dprintf-insert LOCATION FORMAT ARG ARG ...
I like this approach much more.
Thanks for doing it.
Hui> +static char *
Hui> +mi_argv_to_format (int format_num, char **argv, int argc)
This needs an introductory comment explaining the arguments and result.
Hui> + /* If all the string need convert to \ddd mode, so * 2.
Hui> + + 2 for two ".
Hui> + + 1 for \0. */
Hui> + format_size = strlen (argv[format_num]) * 4 + 3;
The comment says "* 2" but the code says "* 4".
Personally I'd just use an obstack rather than mess around with explicit
reallocs and the like.
Hui> + sprintf (format + format_current_size, "\\%o",
Hui> + argv[format_num][i]);
It seems that this could do the wrong thing for a char that
sign-extends.
Hui> + /* Apply other argv to FORMAT. */
Hui> + for (i = format_num + 1; i < argc; i++)
It seems to me that it would be better to just pass in argv+argc to
mi_argv_to_format, and omit the format_num argument entirely.
Hui> +static void
Hui> +mi_cmd_break_insert_1 (int dprintf, char *command, char **argv, int argc)
Intro comment.
Hui> + extra_string = mi_argv_to_format (oind + 1, argv, argc);
Hui> + make_cleanup (xfree, extra_string);
This makes a dangling cleanup.
Hui> + if (tracepoint)
Hui> + {
Hui> + /* Note that to request a fast tracepoint, the client uses the
Hui> + "hardware" flag, although there's nothing of hardware related to
Hui> + fast tracepoints -- one can implement slow tracepoints with
Hui> + hardware breakpoints, but fast tracepoints are always software.
Hui> + "fast" is a misnomer, actually, "jump" would be more appropriate.
Hui> + A simulator or an emulator could conceivably implement fast
Hui> + regular non-jump based tracepoints. */
Hui> + type_wanted = hardware ? bp_fast_tracepoint : bp_tracepoint;
Hui> + ops = &tracepoint_breakpoint_ops;
Hui> + }
Hui> + else if (dprintf)
Hui> + {
It seems that 'tracepoint' and 'dprintf' are exclusive, so this should
be checked above where "hardware" is checked.
Tom
next prev parent reply other threads:[~2013-05-07 20:50 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 17:44 Hui Zhu
2013-03-28 18:37 ` Eli Zaretskii
2013-03-29 16:12 ` Hui Zhu
2013-03-29 16:13 ` Eli Zaretskii
2013-04-09 23:31 ` Pedro Alves
2013-04-10 19:44 ` Marc Khouzam
2013-04-10 19:45 ` Pedro Alves
2013-04-11 6:15 ` Hui Zhu
2013-04-11 17:47 ` Pedro Alves
2013-04-12 14:56 ` Hui Zhu
2013-04-12 15:22 ` Pedro Alves
2013-04-15 18:59 ` Hui Zhu
2013-04-15 19:41 ` Pedro Alves
2013-04-16 9:31 ` Hui Zhu
2013-04-22 1:25 ` Yao Qi
2013-04-12 16:03 ` Eli Zaretskii
2013-04-13 14:16 ` Tom Tromey
2013-04-15 18:04 ` Hui Zhu
2013-04-15 19:36 ` Pedro Alves
2013-04-16 9:31 ` Hui Zhu
2013-04-22 0:18 ` Tom Tromey
2013-04-22 9:07 ` Hui Zhu
2013-04-25 6:51 ` Tom Tromey
2013-05-03 5:43 ` Hui Zhu
2013-05-07 20:50 ` Tom Tromey [this message]
2013-05-10 10:57 ` Hui Zhu
2013-05-10 15:24 ` Tom Tromey
2013-05-11 2:38 ` Hui Zhu
2013-05-11 7:29 ` Eli Zaretskii
2013-05-13 3:39 ` Hui Zhu
2013-05-13 15:55 ` Eli Zaretskii
2013-05-14 4:56 ` Hui Zhu
2013-05-20 7:31 ` Hui Zhu
2013-05-20 15:44 ` Eli Zaretskii
2013-05-21 4:25 ` Hui Zhu
2013-05-21 8:10 ` [patch] Fix racy FAILs due to "read1" [Re: [PATCH] add -s option to make -break-insert support dprintf] Jan Kratochvil
2013-05-21 9:30 ` Hui Zhu
2013-05-21 15:01 ` [commit] " Jan Kratochvil
2013-05-22 1:05 ` Hui Zhu
2013-05-23 14:03 ` [patch] Fix racy FAILs #2 " Jan Kratochvil
2013-05-24 15:37 ` [commit] " Jan Kratochvil
2013-05-27 11:02 ` Hui Zhu
2013-05-13 16:23 ` [PATCH] add -s option to make -break-insert support dprintf Tom Tromey
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=87d2t2tt02.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=hui_zhu@mentor.com \
--cc=marc.khouzam@ericsson.com \
--cc=palves@redhat.com \
--cc=teawater@gmail.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