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: Terry Lambert <email@hidden>
- Date: Wed, 12 Aug 2009 17:49:17 -0700
On Aug 12, 2009, at 3:25 PM, Rick Mann wrote:
I'm guessing I'm going to need to change this code. It uses ucontext
to get the sigcontext, and then uses that to save off some registers
and optionally deal with some error state.
Is there a way to do that without relying on a fragile API?
Can you get chip vendors to stop making new chips with new features
that might need information saved on a context switch?
POSIX pretty much nails us to a non-opaque cross for all time for the
ucontext_t and mcontext_t because it mandates that we expose the
ucontext_t elements directly off a cast pointer, and it mandates that
getcontext() take a ucontext_t that might have been statically
declared, instead of treating it opaquely, and there's no
corresponding destroycontext() (a pointer to a pointer would have been
ideal for the ucontext_t type, with accessor and mutator functions
which could be vendor defined, the way it's possible to implement
posix_spawn()).
I can (probably) post some of our code if it helps. But we basically
do this:
#if defined( HAVE_BSD_STYLE_SIGNALS )
#define SIGCONTEXT_MEMBER(x, y) ( static_cast< unsigned long >( x-
>sc_##y ) )
#endif
void Global_sigaction_handler( int signum, siginfo_t *sinfo, void
*arg )
{
struct ucontext * uc = reinterpret_cast<struct ucontext *>( arg );
struct sigcontext * context = (struct sigcontext *)&uc-
>uc_mcontext;
...
HAL_SavedRegisters regs;
regs.edi = SIGCONTEXT_MEMBER( context, edi );
regs.esi = SIGCONTEXT_MEMBER( context, esi );
...etc...
}
Is there an alternative way to implement this?
Realize the code will not necessarily be portable between versions of
the OS (POSIX is what added the __'s to endure against namespace
pollution), and the binaries will not necessarily be portable between
software updates, since we reserve the right to plop down pretty much
any modified version of a context structure on the user stack we need
to in order to support a hardware platform, and then pass a pointer to
that as the new ucontext_t/mcontext_t type.
Also realize that mcontext_t is implementation defined, and we've
defined it as a pointer that points someplace on the stack after the
ucontext_t, without definition anything about packing or anything else
it'd be convenient to nail down, if you didn't want to have to rev
your product on software updates, just like we potentially have to rev
gdb, Java, and our other tools that know about the internals of these
things on software updates.
This cruft is NOT API. If you break on an SU because we change it,
you fix it.
-- Terry
///////////////////////////////////
#define _XOPEN_SOURCE 600L /* This is pretty clearly documented in
<ucontexh.h> */
#include <stdio.h>
#include <ucontext.h>
/*
* some fake data so I don't really have to write a signal handler
and make it fire
* to demonstrate successfully accessing structure members of the
mcontext...
*/
ucontext_t foo;
char *buf[1024];
mcontext_t fee = (void *)buf;;
/* A small program that proves we actually accessed them */
int
main(int ac, char *av[])
{
#if __LP64
unsigned long long save_rdi = fee->__ss.__rdi;
#else
unsigned long save_edi = fee->__ss.__edi;
#endif
printf("I compiled with the definition in scope\n");
return 0;
}
///////////////////////////////////
_______________________________________________
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