Re: Breakpoint Implementation
Re: Breakpoint Implementation
- Subject: Re: Breakpoint Implementation
- From: Dave Keck <email@hidden>
- Date: Thu, 7 Oct 2010 03:59:03 -0400
> 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.
Clever - that sounds like the answer I was looking for.
> (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.)
Is that necessary? With this instruction buffer technique, when Thread
A hits Breakpoint A:
1. Suspend every thread
2. Let user handle breakpoint
3. Cache Thread A's EIP
4. Set EIP of Thread A to detached instruction buffer filled with
'syscall; int 3'
5. Resume every thread
6. When Thread A hits the INT3 from step #4, set Thread A's EIP to the
instruction after the cached EIP (from step #3) and resume
Since Thread B won't be spawned until step #5 -- after the user has
handled the breakpoint and chosen to continue -- I don't see Thread
B's actions as being an issue.
Thanks,
David
_______________________________________________
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