• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mach-exception forwarding changed on Leopard?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mach-exception forwarding changed on Leopard?


  • Subject: Re: Mach-exception forwarding changed on Leopard?
  • From: Carl Seleborg <email@hidden>
  • Date: Mon, 16 Jun 2008 17:44:02 +0200
  • Organization: Ableton AG

Hello again,

Thanks to those who proposed various solutions. It turns out that the problem was a bit different.

The biggest problem was that the catch_exception_raise() function and its two other versions need to have their "visibility" attribute set to "default", so the correct way to implement them was *with* the visibility attribute declaration:

extern "C"
{
  __attribute__ ((visibility("default")))
  kern_return_t catch_exception_raise(/*...*/)
  {
    // ...
  }
}

Not having this extra attribute declaration resulted in a linker warning in my release build (see next paragraph).


The other problem I had was that my debug build is split in a bunch of dynamic libs, and these three functions were implemented in one of them. This caused whoever it is that looks these functions up not to find them. This, in turn, resulted in task_get_exception_ports() to return a NULL port (there was one returned record, but its port member was MACH_PORT_NULL). So my own exception handler was of course not called, and the application remained blocked in some default-provided implementation of these functions. The all-in-one release build did not have this problem. (Maybe this can be solved by "pre-heating" the symbols e.g. by calling those functions early on, I just thought of that but won't have time to try it)



The last problem I had was with GCC not being able to break at the point where the exception occurs when my own handler is installed. I thought that it installed a crappy value for the behavior (which should be one of EXCEPTION_DEFAULT, EXCEPTION_STATE or EXCEPTION_STATE_IDENTITIY). But upon closer inspection, it turns out it was one of those values, or-ed with the constant MACH_EXCEPTION_CODES (0x80000000) which only appear in the 10.5 version of SDK. I am building on 10.5 (so GCC was built with this constant) but against the 10.4 version of the SDK which is why I did not know about that define.


Now, when this bit is set, the calls to forward the exception are not exception_raise() and friends, but mach_exception_raise() and friends.

It turns out however that when I just return KERN_FAILURE if this bit is set, the debugger will correctly break at the point of exception on 10.5 (not on 10.4, however!).


So that was my experience of it. To sum up: 1. Visibility attribute needed to be "default".

2. Exception handling does not play well when your catch_exception_raise() and friends functions are implemented in dynamic libraries.

3. Need to be careful when the behavior member of the already-installed exception handler has the MACH_EXCEPTION_CODES bit set.


Sorry for this lengthy mail, but the documentation is so scarce that I thought this could be useful.


Cheers,

Carl
_______________________________________________
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


  • Prev by Date: Re: Diskarbitration 10.3 and 10.4
  • Next by Date: iPhone SDK Beta 6 Related Sources
  • Previous by thread: Re: Mach-exception forwarding changed on Leopard?
  • Next by thread: Create Process As User
  • Index(es):
    • Date
    • Thread