[9fans] drawterm / linux

[9fans] drawterm / linux

[Reynald AFFELDT]

Hi,

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:

% ./drawterm -a laura -c laura
./drawterm: error stack underflow
abort 2668

 From the newsgroup archive:

http://groups.google.com/groups?hl=en&selm=15125.25433.451914.984165%40nido.hilbert.space

Has anybody solved the problem?

	Thanks.

Re: [9fans] drawterm / linux

[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:

Re: [9fans] drawterm / linux

[William Josephson]

On Thu, Nov 08, 2001 at 11:32:34PM -0500, Steve Kotsopoulos wrote:
> 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]

You'd have to ask Russ to be sure, but I think it is fixed in
drawterm2k.  Isn't there a distributed version that uses pthreads?  If
not, it is a relatively trivial amount of work to get the drawterm
threads to run on top of pthreads.  I thought that was how the public
version works under FreeBSD and Windows anyway.  You can also replace
the pipe-lock hack with sleep/wakeup on top of pthreads, although for
drawterm I doubt the difference would be noticeable.  (It is for
things like McIlroy's squint, which is what I use to test my Unix port
of the Plan 9 thread library).

 -WJ

Re: [9fans] drawterm / linux

[William Josephson]

On Thu, Nov 08, 2001 at 11:50:06PM -0500, William Josephson wrote:
> On Thu, Nov 08, 2001 at 11:32:34PM -0500, Steve Kotsopoulos wrote:
> > 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.
>
> drawterm I doubt the difference would be noticeable.  (It is for
> things like McIlroy's squint, which is what I use to test my Unix port
> of the Plan 9 thread library).

Um.  Rob's squint, McIlroy's power series code
("Squinting at power series"). No more posting
without adequate sleep...

And while we're at it, re: GPL nonsense
(1) it is arrogant to expect a company to
    give away software in the first place.
    open standards when they apply, but not code.
(2) don't go around telling people they haven't
    done enough to make Plan 9 free when you don't
    know what you're talking about.

</rant>

Re: [9fans] drawterm / linux

[Thomas Bushnell, BSG]

jkw@eecs.harvard.edu (William Josephson) writes:

> And while we're at it, re: GPL nonsense
> (1) it is arrogant to expect a company to
>     give away software in the first place.
>     open standards when they apply, but not code.

If a company doesn't want to make the code free software, that's its
business.  I'm not saying Lucent is immoral or defective, just that
one reason lots of people aren't using Plan 9 is because it comes
encumbered with liberty-destroying provisions.

> (2) don't go around telling people they haven't
>     done enough to make Plan 9 free when you don't
>     know what you're talking about.

I'm saying that the Lucent lawyers haven't made it free.  Whether they
want to make it free or not is their business.  But the fact that they
haven't means that lots of people who would use Plan 9, don't.

As for the patent problems, I still wonder whether Rob Pike has
decided he did understand the applications after all, and if so, if he
might tell the world exactly what is and is not covered by patents in
Plan 9.

Re: [9fans] drawterm / linux

[Ish Rattan]

On Thu, 8 Nov 2001, Steve Kotsopoulos wrote:

> 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]
Using POSIX threads solves the problem (it worked for me).

-ishwar

Re: [9fans] drawterm / linux

[Steve Kotsopoulos]

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:
>
> % ./drawterm -a laura -c laura
> ./drawterm: error stack underflow
> abort 2668

sorry, I should have dug around a bit more before posting.
This appears to be a solution ... let us know if it works

>From: Ish Rattan <ishwar@pali.cps.cmich.edu>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] drawterm and linux 2.4.4 SMP
Date: Sat, 21 Jul 2001 00:28:58 -0400 (EDT)

Linux kernel-2.4.3
Glibc-2.2.2

----mkfile-Linux---
WIN=x11
OS=posix

CC=cc
CFLAGS=-g -c -DLINUX -I/usr/X11R6/include
TARG=drawterm
O=o
LD=cc
LDFLAGS=-g -static -o drawterm

DEVIP=devip-unix
DEVFS=devunixfs
OSFILES=md-iprint.$O canlock-x86-gcc.$O
LIBS=-lpthread -lm -L/usr/X11R6/lib -lX11

ml-%.$O:        $DSRC/libmemlayer/%.c
        $CC $CFLAGS -o ml-$stem.o $DSRC/libmemlayer/$stem.c

md-%.$O:        $DSRC/libmemdraw/%.c
        $CC $CFLAGS -o md-$stem.o $DSRC/libmemdraw/$stem.c

d-%.$O: $DSRC/libdraw/%.c
        $CC $CFLAGS -o d-$stem.o $DSRC/libdraw/$stem.c

Re: [9fans] drawterm / linux

[Reynald AFFELDT]

> sorry, I should have dug around a bit more before posting.
I should have searched a bit more too. :-|

> This appears to be a solution ... let us know if it works
Yes, the executable yielded by that mkfile seems to work as
intended.

	Thanks a lot. :-)

Re: [9fans] drawterm / linux

[rob pike]

[-- Attachment #1: Type: text/plain, Size: 102 bytes --]

Try linking the binary to make a statically-linked program instead
of dynamically-linked.

-rob


[-- Attachment #2: Type: message/rfc822, Size: 1830 bytes --]

From: Reynald AFFELDT <affeldt@is.s.u-tokyo.ac.jp>
To: 9fans@cse.psu.edu
Subject: [9fans] drawterm / linux
Date: Fri, 09 Nov 2001 13:06:38 +0900
Message-ID: <20011109130638-16803A.affeldt@harp.is.s.u-tokyo.ac.jp>


Hi,

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:

% ./drawterm -a laura -c laura
./drawterm: error stack underflow
abort 2668

 From the newsgroup archive:

http://groups.google.com/groups?hl=en&selm=15125.25433.451914.984165%40nido.hilbert.space

Has anybody solved the problem?

	Thanks.

Re: [9fans] drawterm / linux

[David Gordon Hogan]

> > Has anyone solved this? [not sure if rob's suggestion of
> > statically-linking was taking the above into account or not]
> Using POSIX threads solves the problem (it worked for me).

I have a partially completed port of drawterm && inferno to the
new 9P2000 regime, and for Linux I use Posix threads.  Not sure
when I'll get around to getting this out.