From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200111090432.fA94WZc10106@fywss.com> To: 9fans@cse.psu.edu From: steve@fywss.com (Steve Kotsopoulos) Subject: Re: [9fans] drawterm / linux In-reply-to: Your message of "Fri, 09 Nov 2001 13:06:38 +0900." <20011109130638-16803A.affeldt@harp.is.s.u-tokyo.ac.jp> Date: Thu, 8 Nov 2001 23:32:34 -0500 Topicbox-Message-UUID: 1a890fac-eaca-11e9-9e20-41e7f4b1d025 This sounds like the problem that you hit when running a linux 2.4 series kernel, caused by the 'thread switch hack' not working with that kernel. Has anyone solved this? [not sure if rob's suggestion of statically-linking was taking the above into account or not] Here's a message from jmk on this issue, and a followup from viro: >From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] drawterm and linux 2.4.4 SMP Date: Fri, 20 Jul 2001 22:38:30 -0400 On Fri Jul 20 21:16:24 EDT 2001, crdevilb@mtu.edu wrote: > I remember there was talk on the list some time ago about drawterm for > linux and how it may very well be broken under linux 2.4; well, that > time is here. It seems (to me) that it is broken because I was just > stepping through the source (because it was SEGVing), and the macro CT > (at linux.c:30) seems to nondeterministically alternate between giving > the right answer and giving NULL, because linux.c:/^gettss(void) > nondeterministically alternates between returning 6 and 8... > > Was there some suggestion or patch anybody had to fix this, or am I > going to be digging into the linux kernel to find yet another hack to > solve this? > > Thanks in advance for any help. > > -- > Colin DeVilbiss > crdevilb@mtu.edu I haven't looked at that code but from the description it looks like the thread switch hack Phil Winterbottom and I did when we ported Inferno to Linux a very long time ago. At that time Linux used the task switch capabililty of the x86 (why, I don't know) so it was possible to use the contents of the task-switch register as an index to find the process context in the shared memory as there was no other private per-process memory available (Plan 9 at least gives each process a private stack). You will need to find some other way to do it, but it will probably be just as much of a hack. I don't know what possibilities there are under Linux 2.4, but they must surely have added something (that could be used). Perhaps someone who is more familiar with both the thread-switching scheme used in drawterm and Linux can give a better answer. >From: Alexander Viro To: 9fans@cse.psu.edu Subject: Re: [9fans] drawterm and linux 2.4.4 SMP Date: Fri, 20 Jul 2001 22:43:27 -0400 (EDT) On Sat, 21 Jul 2001 crdevilb@mtu.edu wrote: > Was there some suggestion or patch anybody had to fix this, or am I > going to be digging into the linux kernel to find yet another hack to > solve this? Check the archives. BTW, there _is_ a dirty hack that will work on slightly modified 2.4 (x86). So if you are into really kinky stuff - try to play with the following idea: let sys_fork() and sys_clone() set cr2 to current->pid before returning into (child's) userland. Ditto on the exit from do_page_fault(). Then you are guaranteed that in userland cr2 will be always equal to value of getpid(2). Mechanics behind this ugliness: a) cr2 is never directly assigned - neither by kernel nor by userland b) it is clobbered by pagefault exception (MMU sets it to address that had caused fault) c) pagefault handler reads its value in the very beginning and doesn't use cr2 after that. IIRC, that had been proposed as a proof-of-concept implementation of getpid() without syscalls. It should even be 'portable' to other systems running on x86 - e.g. in case of Plan 9 you'd need to s/current/up/ and s/do_page_fault/fault386/. ISTR author of that hack claiming that other architectures usually allow something similar - rarely used registers that are clobbered only in situations when we have access to task_struct and know that thing had been clobbered. IMO it's a dirty hack, but then so was the use of TSS... Reynald AFFELDT wrote: > > After compilation of drawterm under Linux (Linux 2.4.2 (Red Hat 7.1) / > gcc 2.96), I got the following error message when executing the > binary: