Re: ucontext.h changes between 10.4 and 10.5?
Re: ucontext.h changes between 10.4 and 10.5?
- Subject: Re: ucontext.h changes between 10.4 and 10.5?
- From: Rick Mann <email@hidden>
- Date: Wed, 12 Aug 2009 17:05:28 -0700
On Aug 12, 2009, at 15:55:08, Terry Lambert wrote:
On Aug 12, 2009, at 11:16 AM, Rick Mann wrote:
I have some code that was compiling when the project was set to
10.4 or "Use Base SDK" (I'm not really sure what that means. In my
project, Base SDK is set to 10.5). But if I compile it with 10.5
(the Overview menu), it fails in a lot of ways, including issues
around ucontext and sigcontext.
Any ideas?
I'm not able to significantly change this code. It's deep in our
custom OS code. Is it just a matter of changing the name of the
struct we're referencing or include a different header?
There were two types of changes made to the ucontext/mcontext header
file definitions:
(1) Changes for UNIX conformance; typically these have to do with
renaming variables that are not allowed to be defined in scope in a
UNIX conformant compilation environment (which 10.5 / 64 bit is by
default).
(2) Changes to make certain definitions opaque to prevent their use
by third parties, without enough difficulty that it should be clear
to the third party that they are messing areound with SPI rather
than API, and that therefore they should expect to potentially need
to recompile their code on each minor release or software update, if
they want it to continue working.
You can always specif a deployment target of 10.4 to get the old
(namespace polluting) header files, or you can update your code to
only use the non-opaque fields, living with some of the renaming
(usually, the addition of __ to things like register names), or you
can include the header files from the relevent system frameworks and/
or published xnu source code, and take your chances on the next
software update.
Personally, I'd break the code in question out into a single
compilation unit, and have everyone call functions from that
compilation unit to mess with the contents of these structures.
Worst case, you could target that one compilation unit to 10.4 to
avoid changes now, and then cleanup breakage if it happens later.
Terry, thanks for the info.
I think I'm going to go ahead and fix our code, but I need to check
with someone else first. In the meantime, I can easily fix the
ucontext name change, but I'm not sure how to get at the machine
registers...is there a way? We log some information during the signal
which includes $eip, and we save off registers in our HAL (I might be
able to change that to use the get/setcontext() calls).
How can I get the registers?
TIA,
Rick
_______________________________________________
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