diff options
| -rw-r--r-- | ChangeLog | 8 | ||||
| -rw-r--r-- | FAQ | 54 | ||||
| -rw-r--r-- | FAQ.in | 52 | ||||
| -rw-r--r-- | elf/elf.h | 1 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h | 6 | ||||
| -rw-r--r-- | sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h | 6 |
6 files changed, 113 insertions, 14 deletions
@@ -1,3 +1,11 @@ +2001-04-05 David S. Miller <davem@redhat.com> + + * elf/elf.h (HWCAP_SPARC_ULTRA3): Define it. + * sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h: Add it to + capability flags table and HWCAP_IMPORTANT, increase + _DL_HWCAP_COUNT to 6. + * sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h: Likewise. + 2001-04-04 David Mosberger <davidm@hpl.hp.com> * sysdeps/unix/sysv/linux/ia64/makecontext.c (__makecontext): Fix @@ -184,6 +184,8 @@ please let me know. 4.8. The conversion table for character set XX does not match with what I expect. 4.9. How can I find out which version of glibc I am using in the moment? +4.10. Context switching with setcontext() does not work from within + signal handlers. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ @@ -1853,12 +1855,56 @@ int main (void) { puts (gnu_get_libc_version ()); return 0; } This interface can also obviously be used to perform tests at runtime if this should be necessary. + +4.10. Context switching with setcontext() does not work from within + signal handlers. + +{DMT} The Linux implementations (IA-64, S390 so far) of setcontext() +supports synchronous context switches only. There are several reasons for +this: + + o UNIX provides no other (portable) way of effecting a synchronous + context switch (also known as co-routine switch). Some versions + support this via setjmp()/longjmp() but this does not work + universally. + + o As defined by the UNIX '98 standard, the only way setcontext() + could trigger an asychronous context switch is if this function + were invoked on the ucontext_t pointer passed as the third argument + to a signal handler. But according to draft 5, XPG6, XBD 2.4.3, + setcontext() is not among the set of routines that may be called + from a signal handler. + + o If setcontext() were to be used for asynchronous context switches, + all kinds of synchronization and re-entrancy issues could arise and + these problems have already been solved by real multi-threading + libraries (e.g., POSIX threads or Linux threads). + + o Synchronous context switching can be implemented entirely in + user-level and less state needs to be saved/restored than for an + asynchronous context switch. It is therefore useful to distinguish + between the two types of context switches. Indeed, some + application vendors are known to use setcontext() to implement + co-routines on top of normal (heavier-weight) pre-emptable threads. + +It should be noted that if someone was dead-bent on using setcontext() +on the third arg of a signal handler, then IA-64 Linux could support +this via a special version of sigaction() which arranges that all +signal handlers start executing in a shim function which takes care of +saving the preserved registers before calling the real signal handler +and restoring them afterwards. In other words, we could provide a +compatibility layer which would support setcontext() for asynchronous +context switches. However, given the arguments above, I don't think +that makes sense. setcontext() provides a decent co-routine interface +and we should just discourage any asynchronous use (which just calls +for trouble at any rate). + ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Answers were given by: -{UD} Ulrich Drepper, <drepper@cygnus.com> -{DMT} David Mosberger-Tang, <davidm@AZStarNet.com> +{UD} Ulrich Drepper, <drepper@redhat.com> +{DMT} David Mosberger-Tang, <davidm@hpl.hp.com> {RM} Roland McGrath, <roland@gnu.org> {AJ} Andreas Jaeger, <aj@suse.de> {EY} Eric Youngdale, <eric@andante.jic.com> @@ -1866,10 +1912,10 @@ Answers were given by: {MK} Mark Kettenis, <kettenis@phys.uva.nl> {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> {TK} Thorsten Kukuk, <kukuk@suse.de> -{GK} Geoffrey Keating, <geoffk@ozemail.com.au> +{GK} Geoffrey Keating, <geoffk@redhat.com> {HJ} H.J. Lu, <hjl@gnu.org> {CG} Cristian Gafton, <gafton@redhat.com> -{AO} Alexandre Oliva, <oliva@lsd.ic.unicamp.br> +{AO} Alexandre Oliva, <aoliva@redhat.com> {BH} Bruno Haible, <haible@clisp.cons.org> Local Variables: @@ -1596,10 +1596,54 @@ int main (void) { puts (gnu_get_libc_version ()); return 0; } This interface can also obviously be used to perform tests at runtime if this should be necessary. +?? Context switching with setcontext() does not work from within + signal handlers. + +{DMT} The Linux implementations (IA-64, S390 so far) of setcontext() +supports synchronous context switches only. There are several reasons for +this: + + o UNIX provides no other (portable) way of effecting a synchronous + context switch (also known as co-routine switch). Some versions + support this via setjmp()/longjmp() but this does not work + universally. + + o As defined by the UNIX '98 standard, the only way setcontext() + could trigger an asychronous context switch is if this function + were invoked on the ucontext_t pointer passed as the third argument + to a signal handler. But according to draft 5, XPG6, XBD 2.4.3, + setcontext() is not among the set of routines that may be called + from a signal handler. + + o If setcontext() were to be used for asynchronous context switches, + all kinds of synchronization and re-entrancy issues could arise and + these problems have already been solved by real multi-threading + libraries (e.g., POSIX threads or Linux threads). + + o Synchronous context switching can be implemented entirely in + user-level and less state needs to be saved/restored than for an + asynchronous context switch. It is therefore useful to distinguish + between the two types of context switches. Indeed, some + application vendors are known to use setcontext() to implement + co-routines on top of normal (heavier-weight) pre-emptable threads. + +It should be noted that if someone was dead-bent on using setcontext() +on the third arg of a signal handler, then IA-64 Linux could support +this via a special version of sigaction() which arranges that all +signal handlers start executing in a shim function which takes care of +saving the preserved registers before calling the real signal handler +and restoring them afterwards. In other words, we could provide a +compatibility layer which would support setcontext() for asynchronous +context switches. However, given the arguments above, I don't think +that makes sense. setcontext() provides a decent co-routine interface +and we should just discourage any asynchronous use (which just calls +for trouble at any rate). + + Answers were given by: -{UD} Ulrich Drepper, <drepper@cygnus.com> -{DMT} David Mosberger-Tang, <davidm@AZStarNet.com> +{UD} Ulrich Drepper, <drepper@redhat.com> +{DMT} David Mosberger-Tang, <davidm@hpl.hp.com> {RM} Roland McGrath, <roland@gnu.org> {AJ} Andreas Jaeger, <aj@suse.de> {EY} Eric Youngdale, <eric@andante.jic.com> @@ -1607,10 +1651,10 @@ Answers were given by: {MK} Mark Kettenis, <kettenis@phys.uva.nl> {ZW} Zack Weinberg, <zack@rabi.phys.columbia.edu> {TK} Thorsten Kukuk, <kukuk@suse.de> -{GK} Geoffrey Keating, <geoffk@ozemail.com.au> +{GK} Geoffrey Keating, <geoffk@redhat.com> {HJ} H.J. Lu, <hjl@gnu.org> {CG} Cristian Gafton, <gafton@redhat.com> -{AO} Alexandre Oliva, <oliva@lsd.ic.unicamp.br> +{AO} Alexandre Oliva, <aoliva@redhat.com> {BH} Bruno Haible, <haible@clisp.cons.org> Local Variables: @@ -1117,6 +1117,7 @@ typedef struct #define HWCAP_SPARC_SWAP 4 #define HWCAP_SPARC_MULDIV 8 #define HWCAP_SPARC_V9 16 /* The cpu is v9, so v8plus is ok. */ +#define HWCAP_SPARC_ULTRA3 32 /* MIPS R3000 specific definitions. */ diff --git a/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h b/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h index 39cb841..61d9d8c 100644 --- a/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h +++ b/sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h @@ -27,9 +27,9 @@ is still ok with the given array size. */ static const char sparc32_cap_flags[][7] = { - "flush", "stbar", "swap", "muldiv", "v9" + "flush", "stbar", "swap", "muldiv", "v9", "ultra3" }; -#define _DL_HWCAP_COUNT 5 +#define _DL_HWCAP_COUNT 6 static inline int __attribute__ ((unused)) @@ -68,7 +68,7 @@ _dl_string_hwcap (const char *str) return -1; }; -#define HWCAP_IMPORTANT (HWCAP_SPARC_V9) +#define HWCAP_IMPORTANT (HWCAP_SPARC_V9|HWCAP_SPARC_ULTRA3) /* There are no different platforms defined. */ #define _dl_platform_string(idx) "" diff --git a/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h b/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h index 5833902..23bfd47 100644 --- a/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h +++ b/sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h @@ -27,9 +27,9 @@ is still ok with the given array size. */ static const char sparc64_cap_flags[][7] = { - "flush", "stbar", "swap", "muldiv", "v9" + "flush", "stbar", "swap", "muldiv", "v9", "ultra3" }; -#define _DL_HWCAP_COUNT 5 +#define _DL_HWCAP_COUNT 6 static inline int __attribute__ ((unused)) @@ -69,7 +69,7 @@ _dl_string_hwcap (const char *str) return -1; }; -#define HWCAP_IMPORTANT (0) +#define HWCAP_IMPORTANT (HWCAP_SPARC_ULTRA3) /* There are no different platforms defined. */ #define _dl_platform_string(idx) "" |