Re: determining the stack bounds

2008-06-06 Thread Bruno Haible
Eric Blake wrote: > On Solaris 8, uc_stack is (IMHO properly) pointing to the primary stack, > even though the handler is executing on the alternate stack. That's accidental, IMO. The only documented use of uc_stack in POSIX:2001 is in the description of 'makecontext', as an input parameter. Its

Re: determining the stack bounds

2008-06-06 Thread Eric Blake
Eric Blake byu.net> writes: > > > > On the other hand, POSIX states for sigaction() that the handler's "third > > argument can be cast to a pointer to an object of type ucontext_t to refer to > > the receiving thread’s context that was interrupted when the signal was > > delivered." > | > |>

Re: determining the stack bounds

2008-06-06 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 6/6/2008 6:25 AM: | According to Bruno Haible on 6/6/2008 5:29 AM: | | The type of the third argument, according to POSIX, is 'void *ucp'. | Why does | | it have to be cast? Why is it not directly 'ucontext_t *ucp' (since, |

Re: determining the stack bounds

2008-06-06 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 6/6/2008 5:29 AM: | The type of the third argument, according to POSIX, is 'void *ucp'. Why does | it have to be cast? Why is it not directly 'ucontext_t *ucp' (since, as you | say, ucontext_t will be defined in )? I thin

Re: determining the stack bounds

2008-06-06 Thread Bruno Haible
Eric Blake wrote: > On the other hand, POSIX states for sigaction() that the handler's "third > argument can be cast to a pointer to an object of type ucontext_t to refer to > the receiving thread’s context that was interrupted when the signal was > delivered." The type of the third argument, ac

Re: determining the stack bounds

2008-06-05 Thread Eric Blake
Bruno Haible clisp.org> writes: > > Eric Blake wrote: > > user_context->uc_stack.ss_sp contains the location > > of the currently running (alternate) stack, not the stack where the fault > > occurred. ... find out where the _original_ stack ended I'm not sure if it is a bug or intentional t

Re: determining the stack bounds

2008-06-05 Thread Bruno Haible
Eric Blake wrote: > user_context->uc_stack.ss_sp contains the location > of the currently running (alternate) stack, not the stack where the fault > occurred. ... find out where the _original_ stack ended > ... > I haven't looked at how libsigsegv handles this situation libsigsegv has a soluti