Re: [9fans] drawterm / linux

[steve@fywss.com (Steve Kotsopoulos)]

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 <viro@math.psu.edu>
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: