This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] dynamic printf
- From: Tom Tromey <tromey at redhat dot com>
- To: Stan Shebs <stanshebs at earthlink dot net>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, gdb-patches at sourceware dot org
- Date: Wed, 14 Mar 2012 09:27:48 -0600
- Subject: Re: [PATCH] dynamic printf
- References: <4F4DCDD5.2040807@earthlink.net> <m2fwduc883.fsf@igel.home> <4F5FD3A6.1090106@earthlink.net>
>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:
Stan> Another consideration is how the collection looks in an info break
Stan> command. If dynamic prints are a different kind of breakpoint, then
Stan> you can (in theory) filter the breakpoint listing to a single
Stan> category, but if they are just breakpoints with special commands,
Stan> they'll continue to be in the big list.
I tend to prefer a new command for this reason and also KISS.
Stan> My intuition isn't giving me a strong read on which approach users
Stan> will like better. As the goal is at least partly to entice
Stan> printf()+recompile users into using a GDB command instead, I think it
Stan> needs to be among GDB's simpler commands. Maybe include both
Stan> syntaxes, mapping down to same functionality?
dprintf breakpoints have different semantics from regular breakpoints,
too, don't they? They are non-stopping.
It seems to me that if you go the suffix route, then you also need ways
to control the stopping-ness, and to change or delete the printf stuff.
I think it is simpler and hardly any less convenient for users to just
have dprintf and regular breakpoints be separate things.
If we get a flood of bug reports to the contrary, we can always go back
and add the printf qualifier later.
Tom