This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [reverse/record] adjust_pc_after_break in reverse execution mode?


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
>>
>

Attachment: record_wait_breakpoint.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]