This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [reverse/record] adjust_pc_after_break in reverse execution mode?
Hi Pedro and Michael,
How do you think about the patch in
http://sourceware.org/ml/gdb-patches/2008-10/msg00634.html
Thanks,
Hui
On Sat, Oct 25, 2008 at 15:07, teawater <teawater@gmail.com> wrote:
> The old patch make my_waitpid_record set pc even if this is not a breakpoint.
> So I make a new patch that my_waitpid_record just set pc when this is
> a breakpoint.
>
>
> 2008-10-24 Hui Zhu <teawater@gmail.com>
>
> * record.c (record_wait): Check breakpint before forward
> execute in replay mode.
> Check breakpoint use function "breakpoint_inserted_here_p"
> in replay mode.
> Set pc if forward execute, gdbarch_decr_pc_after_break is not
> 0 and this is not single step in replay mode.
>
> * linux-nat.c (my_waitpid_record): Add
> gdbarch_decr_pc_after_break to pc if need.
>
>
>
> On Fri, Oct 24, 2008 at 17:57, teawater <teawater@gmail.com> wrote:
>> Hi buddies,
>>
>> This is the new patch that fix the break bug.
>>
>> But I think I still need to add some code to deal with signal.
>>
>> 2008-10-24 Hui Zhu <teawater@gmail.com>
>>
>> * record.c (record_wait): Check breakpint before forward
>> execute in replay mode.
>> Check breakpoint use function "breakpoint_inserted_here_p"
>> in replay mode.
>> Set pc if forward execute, gdbarch_decr_pc_after_break is not
>> 0 and this is not single step in replay mode.
>>
>> * linux-nat.c (my_waitpid_record): Add
>> gdbarch_decr_pc_after_break to pc if need.
>>
>> Thanks,
>> Hui
>>
>> On Fri, Oct 24, 2008 at 16:10, teawater <teawater@gmail.com> wrote:
>>> Thanks Pedro and Michael,
>>>
>>> I think the reason is P record let inferior step recycle in the
>>> linux-nat target.
>>> So when it break by breakpint, it will not let
>>> (pc+gdbarch_decr_pc_after_break (gdbarch)). Then after
>>> adjust_pc_after_break, The PC is error.
>>>
>>> I will try to deal with it.
>>>
>>> Hui
>>>
>>> On Fri, Oct 24, 2008 at 09:50, Pedro Alves <pedro@codesourcery.com> wrote:
>>>> On Friday 24 October 2008 01:37:31, Michael Snyder wrote:
>>>>> > In sum, it appears that decr_pc_after_break doesn't matter when you have
>>>>> > continguous breakpoints, as long as you get from from B1's address to B2's
>>>>> > address by single-stepping. All is good then, it appears!
>>>>>
>>>>> I agree, at least that is the conclusion I am leaning toward.
>>>>>
>>>>
>>>> Not so fast! I knew I had to spend a little extra thinking about
>>>> it, 'cause I knew something was broken, just couldn't find what. :-)
>>>> *as long as you get from from B1's address to B2's address
>>>> by single-stepping* was a restriction that doesn't always apply.
>>>>
>>>> Here's a test that will fail in forward record/replay mode, but not
>>>> in normal "play" mode.
>>>>
>>>> volatile int global_foo = 0;
>>>>
>>>> int
>>>> main (int argc, char **argv)
>>>> {
>>>> asm ("nop"); /* 1st insn */
>>>> asm ("nop"); /* 2nd insn */
>>>> asm ("nop"); /* 3rd insn */
>>>> asm ("nop"); /* 4th insn */
>>>> if (!global_foo)
>>>> goto ahead;
>>>> asm ("nop"); /* 5th insn */
>>>> asm ("nop"); /* 6th insn */
>>>> asm ("nop"); /* 7th insn */
>>>> asm ("nop"); /* 8th insn */ <<< break 1 here
>>>> ahead:
>>>> asm ("nop"); /* 9th insn */ <<< break 2 here
>>>> end:
>>>> return 0;
>>>> }
>>>>
>>>> If you let the program reply until break 2 is hit, and assuming insn
>>>> 8th and 9th are assembled as contiguous (they do on x86 -O0 for me), you'll
>>>> see that adjust_pc_after_break will indeed make it appear that breakpoint
>>>> 1 was hit. Now, nops are nops, but real code could have something
>>>> else there...
>>>>
>>>> /me goes back to bed.
>>>>
>>>> --
>>>> Pedro Alves
>>>>
>>>
>>
>