Post a new version according to your comments.  And add test for it.

Thanks,
Hui

2013-03-26  Hui Zhu  <hui@codesourcery.com>

	* breakpoint.c (dprintf_re_set): New.
	(initialize_breakpoint_ops): Set dprintf_breakpoint_ops re_set
	to dprintf_re_set.

2013-03-26  Hui Zhu  <hui@codesourcery.com>

	* gdb.base/Makefile.in (EXECUTABLES): Add dprintf-pending.
	(MISCELLANEOUS): Add dprintf-pendshr.sl.
	* gdb.base/dprintf-pending.c, gdb.base/dprintf-pending.exp: New.

On Sun, Mar 24, 2013 at 8:05 PM, Keith Seitz <keiths@redhat.com> wrote:
> On 03/22/2013 04:12 AM, Yao Qi wrote:
>>>
>>> But if the dprintf is pending.  When it reset by function bkpt_re_set,
>>> there is not code to code to update extra_string to commands.
>>> So I add this code to function update_breakpoint_locations.  The issue
>>> is fixed.
>>
>>
>> The bug was reported in PR breakpoints/15292: Pending dprintf don't
>> work.
>>
>> We need a test case here, I think, to show pending dprintf doesn't
>> work, and it works with your patch applied.
>>
>> I am wondering whether we need a new breakpoint_ops field
>> "parse_extra_string", and use it like:
>>
>>     b->ops->parse_extra_string (b, extra_string);
>>
>> instead of duplicate the code.
>
>
> I agree: special handling is necessary, but I don't care for either of these
> solutions. The original proposal clutters generic breakpoint code with
> dprintf-specific handling. As Yao correctly points out, this is what the
> breakpoint ops vector is for.
>
> However, I don't like the idea of adding a new "parse_extra_string" method.
> It is far too vague. Parse extra_string when?
>
> I think the better solution, and one which we already have the
> infrastructure for, is to define a dprintf_re_set method in the dprintf's
> breakpoint ops, updating the command list whenever a pending breakpoint is
> resolved.
>
> This definitely needs a test.
>
> Keith