Re: x86 inline assembler to stop in debugger

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:

http://lists.apple.com/mailman/options/xcode-users/email@hidden

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:

http://lists.apple.com/mailman/options/xcode-users/email@hidden

This email sent to email@hidden