From 5e01438702688db6e26eab8aee262924c7065ecc Mon Sep 17 00:00:00 2001 From: Ulrich Drepper Date: Thu, 5 Apr 2001 20:45:54 +0000 Subject: [PATCH] Update. 2001-04-05 David S. Miller * 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. --- ChangeLog | 8 ++++ FAQ | 54 ++++++++++++++++++++-- FAQ.in | 52 +++++++++++++++++++-- elf/elf.h | 1 + .../unix/sysv/linux/sparc/sparc32/dl-procinfo.h | 6 +-- .../unix/sysv/linux/sparc/sparc64/dl-procinfo.h | 6 +-- 6 files changed, 113 insertions(+), 14 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5a8426c..ccc0794 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2001-04-05 David S. Miller + + * 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 * sysdeps/unix/sysv/linux/ia64/makecontext.c (__makecontext): Fix diff --git a/FAQ b/FAQ index 955cc54..addc014 100644 --- a/FAQ +++ b/FAQ @@ -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, -{DMT} David Mosberger-Tang, +{UD} Ulrich Drepper, +{DMT} David Mosberger-Tang, {RM} Roland McGrath, {AJ} Andreas Jaeger, {EY} Eric Youngdale, @@ -1866,10 +1912,10 @@ Answers were given by: {MK} Mark Kettenis, {ZW} Zack Weinberg, {TK} Thorsten Kukuk, -{GK} Geoffrey Keating, +{GK} Geoffrey Keating, {HJ} H.J. Lu, {CG} Cristian Gafton, -{AO} Alexandre Oliva, +{AO} Alexandre Oliva, {BH} Bruno Haible, Local Variables: diff --git a/FAQ.in b/FAQ.in index 397b62f..0da2873 100644 --- a/FAQ.in +++ b/FAQ.in @@ -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, -{DMT} David Mosberger-Tang, +{UD} Ulrich Drepper, +{DMT} David Mosberger-Tang, {RM} Roland McGrath, {AJ} Andreas Jaeger, {EY} Eric Youngdale, @@ -1607,10 +1651,10 @@ Answers were given by: {MK} Mark Kettenis, {ZW} Zack Weinberg, {TK} Thorsten Kukuk, -{GK} Geoffrey Keating, +{GK} Geoffrey Keating, {HJ} H.J. Lu, {CG} Cristian Gafton, -{AO} Alexandre Oliva, +{AO} Alexandre Oliva, {BH} Bruno Haible, Local Variables: diff --git a/elf/elf.h b/elf/elf.h index 99503fa..eadded0 100644 --- a/elf/elf.h +++ b/elf/elf.h @@ -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) "" -- 2.7.4