On Tue, Mar 25, 2008 at 07:54:10AM +0000, Bastian Blank wrote: > On Sat, Mar 22, 2008 at 10:02:22PM +0100, Matthias Klose wrote: > > amd64 and i386 side note: the gcc-4.3 4.3.0-2 upload has a patch > > reenabling the cld instruction when stringops are used; this patch is > > neither in the gcc-4_3-branch or in the trunk. > > I discussed with doko a bit and have to propose another solution. This > solution have a prequisite: gcc must not generate string ops without > function calls. > > To understand this solution you have to understand async signal safety > of functions. A signal handler must not call any unsafe function. On a > Debian system this list is in signal(7). All the functions are in the > libc and the libaio. > > The following proposal uses this and should fix any program which does > not use unsafe functions in their signal handlers: > - Add the cld patch to gcc-4.3, the option is disabled by default. > - Build glibc (and maybe libaio) with -mcld. > > Alternative: > - Patch an explicit cld to the beginning of each of the safe functions > in glibc and libaio. >
Problem is that memcpy/memmove/memset probably generate rep stos; in
the end, I believe memset/memcpy/memmove to be async signal safe, and
those are inlined fully in many cases. E.g. it would not be horrible to
see SIGALRM handler that basically do:
void sigalrm_handler(int signo)
{
#if 1
memset(&some_global_struct, 0, sizeof(some_global_struct));
#else /* or alternatively, generating probably the same code, in C99 */
some_global_struct = (some_type){ .some_member = 0 };
#endif
}
So unless I'm mistaken and I miss something obvious, your proposal
doesn't work. And fwiw glibc will be built with gcc-4.2 on i386/amd64 to
avoid any problems as the toolchain freeze is RSN, and that we can't
afford a broken toolchain right now.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpao6lJq8rmi.pgp
Description: PGP signature
