This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Help with implementing ____longjmp_chk for Hurd
- From: Samuel Thibault <samuel dot thibault at gnu dot org>
- To: Thomas Schwinge <tschwinge at gnu dot org>
- Cc: Ulrich Drepper <drepper at redhat dot com>, Roland McGrath <roland at frob dot com>,libc-help at sourceware dot org
- Date: Sun, 23 Aug 2009 23:10:07 +0200
- Subject: Re: Help with implementing ____longjmp_chk for Hurd
- References: <20090808164935.GF26402@fencepost.gnu.org> <20090809114312.GA27209@fencepost.gnu.org>
Thomas Schwinge, le Sun 09 Aug 2009 13:43:13 +0200, a Ãcrit :
> Is it actually allowed to do a longjmp from a signal handler?
Yes. SUS says âlongjmp() shall execute correctly in contexts of
interrupts, signals, and any of their associated functions.â
Actually that's a quite common use, to abort some stuck function for
instance.
> And what about using setjmp and then longjmp in a signal handler?
That should return from the signal handler.
> #ifdef PIC
> -# define CALL_FAIL movl %ebx, %ecx; \
> +# define CALL_FAIL movl %ebx, %ecx; /* TODO: what's this mov good for? */ \
I believe it's just for the following:
> cfi_register(%ebx,%ecx); \
which tells debuggers that we've saved the previous PIC register into
ecx, before loading glibc's:
> LOAD_PIC_REG (bx); \
and using it:
> leal longjmp_msg@GOTOFF(%ebx), %eax; \
> + /* TODO: need locking? */
> + /* struct hurd_sigstate * _hurd_self_sigstate (void) */
Which locking? _hurd_thread_sigstate is already protected by a lock.
Letting it call malloc() in the context of a signal handler may not be
safe though, I don't know whether glibc's malloc can cope with that.
Samuel