This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] add -s option to make -break-insert support dprintf
- From: Pedro Alves <palves at redhat dot com>
- To: Marc Khouzam <marc dot khouzam at ericsson dot com>
- Cc: Hui Zhu <teawater at gmail dot com>, Eli Zaretskii <eliz at gnu dot org>, Hui Zhu <hui_zhu at mentor dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 10 Apr 2013 11:48:10 +0100
- Subject: Re: [PATCH] add -s option to make -break-insert support dprintf
- References: <515451EA dot 1000200 at mentor dot com> <83y5d7wpvq dot fsf at gnu dot org> <CANFwon23qn_SVjcUWUZ2Z2Y5Euqg8efiwMvXkxTRtA9-2Ttk3Q at mail dot gmail dot com>,<516454DA dot 9040109 at redhat dot com> <E59706EF8DB1D147B15BECA3322E4BDC1BF1EB72 at eusaamb110 dot ericsson dot se>
Hi Marc,
On 04/10/2013 11:31 AM, Marc Khouzam wrote:
> In the orginal patch, having both 'hardware' and 'dprintf' true would
> create a hardware breakpoint (not dprintf), but would still set 'ops'
> to &dprintf_breakpoint_ops. This didn't look right to me.
In fairness, it actually wouldn't, because of:
>>> + if (hardware && dprintf)
>>> + error (_("-break-insert: -h and -s cannot be use together"));
I guess my change at least makes it more obvious in that other
spot too.
> A side-effect of Pedro's change is that the hardware dprintf case
> will be handled properly. I think that is a good thing. However,
> I wanted to mention it, as I don't know if there are other changes
> needed to handle a hardware dprintf (or if it really should be allowed).
> I am allowed to create a hardware breakpoint with a printf condition,
> so I guess a hardware dprintf would make sense, but I'm not sure.
Yeah, I don't see why it couldn't work. Any kind of
watchpoint/breakpoint, really. To me, this exposes that the whole
dprintf feature hasn't been exposed to the user at the right
abstraction level. It should have been something lower level that
allowed constructing dprintfs, or hardware-dprintfs, or
watchpoints-dprintfs, etc. The python Stop hook is close, except
for the agent side part. Maybe equipping breakpoints with a separate
list of "commands that don't interfere with the current execution
command at time of hit" would have been closer to home.
--
Pedro Alves