site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thanks! On Aug 12, 2009, at 17:49:17, Terry Lambert wrote: ... HAL_SavedRegisters regs; regs.edi = SIGCONTEXT_MEMBER( context, edi ); regs.esi = SIGCONTEXT_MEMBER( context, esi ); ...etc... } #include <stdio.h> #include <ucontext.h> /* 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Thanks for the info, Terry. It's very helpful. I finally found the right engineer here to talk to, and it looks like we only use that information for crash logging, so a) it's okay if the info changes in a new release, and b) we're going to use OS X's crash reporting anyway, so we'll be yanking all this. Sorry to make you go to the effort of explaining it, but it's very educational, anyway, and I'll keep it around for future reference. 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; 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> */ /* * 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;; This email sent to site_archiver@lists.apple.com