This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PPC32 and state of the project
- From: "Kevin.Hendricks" <kevin dot hendricks at sympatico dot ca>
- To: "Steve Munroe" <sjmunroe at us dot ibm dot com>, Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Cc: GNU libc devel <libc-alpha at sources dot redhat dot com>
- Date: Mon, 6 Jan 2003 11:55:33 -0500
- Subject: Re: PPC32 and state of the project
Hi,
Ok you can start by using
linuxthreads/sysdeps/powerpc/powerpc64/pt-machine.h as an example to
start
with. Also you need to look at sysdeps/powerpc/powerpc32/[setjmp.S,
__longjmp.S, /fpu/setjmp.S, /fpu/__longjmp.S]. This is one place (that I
can think of) where the handling of r2 needs to chance ... :)
Perhaps this is a silly question:
Why not save the thread id register when doing a setjmp/longjmp pair?
It should never change across a setjmp, longjmp pair should it?
The only way it should change is that the setjmp buffer is loaded by one
thread and the longjmp is taken by another?
Is this allowed? If so, then you are right and we must remove r2 from
this list?
I could see setjmp/longjmp being used to create psueudo context switches
for multiple user threads on top of one kernel thread perhaps (this is
what Sun did with its jdk green_threads implementation) but I do not
think one would ever move one user thread across different kernel
threads would they?
Kevin
----
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London Ontario, CANADA N6A 3K7
khendricks@ivey.uwo.ca