lkml.org 
[lkml]   [1999]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] string.h speedup, cld-2.3.30-A1

On Sat, 27 Nov 1999, Oliver Xymoron wrote:

> It doesn't appear to, at least according to bits/setjmp.h. Surely, any
> point in a user app can quietly change flags, but Ingo's example of a
> signal handler doing it seemed unlikely.

i just remembered that something in the 'asynchron userland' area needed
to be careful about the direction flag. The patch does not (want to)
change user-space semantics, so this was just a side-comment. Obviously
the state of normal signal handlers are guaranteed by the kernel, but
user-space things like soft-threading and other asynchron mechanizms (like
longjmp) are not necesserily immune to a stale 'std'.

> There's clearly no general fix for the existence of the direction flag
> though, short of getting a non-x86 machine. We could lobby the GCC
> folks for an -fassume-cld and maybe an -fpair-std, but it doesn't
> really fix the problem.

in the kernel the situation is simple: if we protect all doors and windows
going in an out of the kernel then nothing ever can get the direction flag
wrong.

-- mingo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.623 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site