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