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] |
Thanks Pedro. I make a patch too. 2008-10-20 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". Thanks, Hui On Mon, Oct 20, 2008 at 20:09, Pedro Alves <pedro@codesourcery.com> wrote: > A Monday 20 October 2008 01:39:30, Michael Snyder escreveu: >> Pedro Alves wrote: >> > On Sunday 19 October 2008 23:39:20, Michael Snyder wrote: >> >> After codgitating for a bit (that's "thinking" when you're over 50), >> >> I've decided that you're right. >> >> >> >> However, I have a new concern -- I'm worried about what it will do >> >> when it's replaying but going forward. >> >> >> >> Could you possibly revisit your test and see what it does >> >> if you record all the way to line 9 or 10, then back up >> >> to line 6, then continue with breakpoints at 6 and 7? >> > >> > Eh, you're right. It's broken. >> >> Thought so. >> >> See, the problem is that "adjust_pc_after_break" is assuming >> memory-breakpoint semantics, but Process Record/Replay actually >> implements hardware-breakpoint semantics. It watches the >> instruction-address "bus" and stops when the PC matches the >> address of a breakpoint. >> >> I suspect this is probably a problem with other record/replay >> back-ends too, but I haven't confirmed it yet. >> >> Still, I think that the patch you committed was correct >> for the reverse case. > >> This is a corner case that reveals >> that "reverse" and "replay" are not synonymous. > > They certainly aren't. When replaying, I believe it's just best to > behave as close as possible to when it the inferior is really running. > From the inferior control side, GDB be mostly as agnostic about > "replay" vs normal run as possibly. > > IIUC from reading the code, I see two issues. > > 1) When going forward and in reply mode, breakpoint hits are being checked > *after* a record item is replays. IIUC, we should check *before*, > and report an adjusted PC. > > 2) Un-inserted breakpoints weren't accounted for AFAICT (GDB will > un-inserted breakpoints temporarily when stepping over them). > Maybe they are, I got lost. :-) There's a loop going through the > bp_location_chain. Can you get rid of that and use > regular_breakpoint_inserted_here_p or similars? > > Below is a 10 minutes hack at it, as a starting point. Replay stil > isn't perfect, mainly because I got lost in the record_wait maze --- that, > needs a bit of clean up. :-) > >> >> > (gdb) record >> > (gdb) b 6 >> > Breakpoint 2 at 0x8048352: file nop.c, line 6. >> > (gdb) b 7 >> > Breakpoint 3 at 0x8048353: file nop.c, line 7. >> > (gdb) n >> > >> > Breakpoint 3, main () at nop.c:7 >> > 7 asm ("nop"); >> > (gdb) n >> > 8 asm ("nop"); >> > (gdb) >> > 9 asm ("nop"); >> > (gdb) n >> > 10 } >> > (gdb) rc >> > Continuing. >> > >> > Breakpoint 3, main () at nop.c:7 >> > 7 asm ("nop"); >> > (gdb) rn >> > >> > No more reverse-execution history. >> > main () at nop.c:6 >> > 6 asm ("nop"); >> > (gdb) n >> > >> > Breakpoint 2, main () at nop.c:6 >> > 6 asm ("nop"); >> > (gdb) >> > 8 asm ("nop"); >> > (gdb) >> > 9 asm ("nop"); >> > (gdb) >> > >> > >> > >> > -- >> > Pedro Alves >> >> > > > > -- > 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] |