Re: patch for x86 treatment of fs and gs in signal handlers

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Tue, 1 Sep 1998 16:28:23 +0100


On Mon, Aug 31, 1998 at 02:02:40PM -0700, Ulrich Drepper wrote:
> The problem with this approach is that the functionality cannot be
> fully exploited without a gcc extension. How would you defined errno?
> It's no big problem in glibc itself but every program will have
> problems.

I see you noticed the need for a gcc extension if it is done neatly ;-)

> And: if this approach ever should be realized there is no backward
> compatibility. Programs compiled with the new errno definition cannot
> run on old systems. The libc&friends must be compatible. Other
> runtime environments (like FORTRAN etc) must provide the same setup.
> Otherwise it would now be possible to use C written code in this
> environments.

The usual rule is that older programs must run with the newer library.
Programs compiled with the newer library do not really have to run with
older libraries.

However we can achieve both compatibilities.

Use some variant of the proposal whereby thread-local data refers to
ordinary variables but via %gs. Also, make crt0.s copy %ds to %gs.

Then non-threaded programs compiled with the newer library will run
unchanged with older libraries and other environments, whether
dynamically or statically linked. By non-threaded, I simply mean that
the program doesn't use any threads. The code may still be compiled
with threads in mind.

Furthermore, older code that is linked in (statically or not) can still
refer to global values of thread-local data (errno etc.), and code
linked with older Glibc functions for accessing errno the old way can
continue to be supported.

-- Jamie

-
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.altern.org/andrebalsa/doc/lkml-faq.html