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 madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpbV8XhZo471.pgp
Description: PGP signature