Re: x86 inline assembler to stop in debugger
Re: x86 inline assembler to stop in debugger
- Subject: Re: x86 inline assembler to stop in debugger
- From: Jim Ingham <email@hidden>
- Date: Mon, 30 Jan 2006 13:37:51 -0800
Note that gdb knows which TRAPS it sets as breakpoints. If it comes
across another trap, it will NOT treat it as a gdb breakpoint, but
will assume the program wanted it, and will send it on. It also
won't forward you over the trap. You will stop in gdb first, of
course. But getting your program to continue on from there takes a
little work.
OTOH, gdb eats SIGINT's by default. So if you hit the Debugger type
trap, you can just continue from there, and your program will run
past it as if it hadn't hit the trap.
So if you intend to do anything but stop at the trap, then the
Debugger approach is a little nicer. OTOH, if all you want to do is
stop the program dead when you hit that point in your code, either
will do.
Note, all the CarbonCore Debugger call does is pthread_kill with a
SIGINT, so you can roll your own here too if that's more convenient...
Jim
On Jan 30, 2006, at 12:55 PM, Eric Albert wrote:
On Jan 30, 2006, at 12:49 PM, Brad Oliver wrote:
On Jan 30, 2006, at 10:19 AM, Eric Albert wrote:
As far as I can tell -- I haven't tested it -- Debugger() only
breaks if the USERBREAK environment variable is set to 1. In
that case it sends a SIGINT to the current thread. That's not
quite the same as a SIGTRAP.
Is there some condition whereby using another mechanism would be
better, for example running directly from gdb instead of the IDE?
I ask only because I've never had a reason to not use Debugger().
I think -- though the debugger folks might correct me on this --
that trap/int3 is what gdb itself uses for breakpoints, so in
theory it might be "better" somehow. But as long as you're
debugging a program that doesn't have its own SIGINT handler, I
think they'll have the same effect.
-Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden