Re: Breakpoint Implementation
Re: Breakpoint Implementation
- Subject: Re: Breakpoint Implementation
- From: Greg Parker <email@hidden>
- Date: Wed, 6 Oct 2010 12:42:20 -0700
On Oct 4, 2010, at 1:20 AM, Dave Keck wrote: I'm implementing breakpoint functionality in a hobby i386 debugger
using the INT3 instruction. Let's say Thread 1 hits Breakpoint A:
1. Suspend every thread
2. Restore original instruction that was replaced by INT3
3. In Thread 1, EIP--, let Thread 1 single-step (using EFL_TF flag)
4. Revert instruction back to INT3
5. Resume every thread
This technique appears to work as expected, but let's say:
1. Breakpoint A is at the very 'syscall' instruction within
pthread_create() that causes Thread B to spawn
2. Thread B will hit Breakpoint A
Due to the race between Thread B executing and step #4 completing,
couldn't Thread B bypass Breakpoint A?
Yep.
Is there a way to fix this?
Some easy solutions: 1. Ignore it. What are the odds that someone sets a breakpoint on a thread-creation `syscall` in the first place? 2. Disallow setting breakpoints on `syscall` instructions. Then you'll never fail, but people who really want a breakpoint on some `syscall` instruction will need to set a breakpoint somewhere else nearby instead.
A harder solution is to leave the INT3 in place, and set EIP to an instruction buffer of your own on the side that says `syscall ; int3`. That way you can run a syscall instruction on that thread without interfering with any new thread. (Of course, that new thread might stumble over one of your other breakpoints or mutate memory. If you want to handle that, you'd need a breakpoint on the first instruction for new threads, so you can catch the thread there and keep it halted until you're ready to resume threads.)
--
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden