Re: [9fans] any success with current plan9port on sunos5.8?

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

Axel finally jogged my memory far enough back that I remembered
hacking around the yield problem; when I did the diff I did it on
"src", forgetting that that misses "include".

Index: u.h
===================================================================
RCS file: /cvs/plan9/include/u.h,v
retrieving revision 1.4
diff -r1.4 u.h
13c13
< #define __EXTENSIONS__ 1 /* SunOS */
---
> // #define __EXTENSIONS__ 1 /* SunOS */
48,50c48,50
< #	undef _NEEDUSHORT
< #	undef _NEEDUINT
< #	undef _NEEDULONG
---
> //#	undef _NEEDUSHORT
> //#	undef _NEEDUINT
> //#	undef _NEEDULONG

I don't know if there's a good reason for requiring __EXTENSIONS__
to be defined, but it didn't break anything that I can see and
it made the yield problem go away.

Re: [9fans] any success with current plan9port on sunos5.8?

[Charles Forsyth]

__EXTENSIONS__ is possibly needed if you use unistd.h and want the i/o calls to be 64 bit.
that's seems to be the easiest way to get the right combination
with Solaris 2.6.  see /usr/include/unistd.h for an example of how not to do it.
specifically, on some systems including that version of Solaris the `feature' macro definitions
are feature disablers more than feature enablers.

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Richard C Bilson wrote:
...deleted
> I don't know if there's a good reason for requiring __EXTENSIONS__
> to be defined, but it didn't break anything that I can see and
> it made the yield problem go away.

on my plan9port (plan9-20040517.tar.gz)  __EXTENSIONS__ is neccessary to 
compile plan9/src/cmd/9term/SunOS.c . however, i think it is better to 
defined it just for that file. obvious diff included below.

i would like to thank you for the diff to u.h. i also experimented with 
removing __EXTENSIONS__ to get rid of sun-os yield(). however, since i 
failed to remove the 3 #undef _NEED* after <sys/types.h> very little 
compiled properly.
i reinstated __EXTENSIONS__, and after that i slowly got myself totally 
lost in various attempts to get replace yield() with p9yield(). you 
saved me. with your change to u.h (and my change to 9term/SunOS.c) 
everything seems to both compile and run. no changes neccessary to 
fdwait.c, sched.c nor thread.h.


bengt

*** /home/eleberg/private/plan9/src/cmd/9term/SunOS.c.original	Tue Jun 
15 08:42:44 2004
--- /home/eleberg/private/plan9/src/cmd/9term/SunOS.c	Tue Jun 15 
08:42:46 2004
***************
*** 1,4 ****
--- 1,5 ----
   #include <u.h>
+ #define	__EXTENSIONS__
   #include <termios.h>
   #include <stropts.h>
   #include <libc.h>

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

Just some feedback on playing with __EXTENSIONS__.
And some general 'current port' feedback at the end.



I tried the 'do only define __EXTENSIONS__ where necessary approach'
and it turned out to be pretty painful, when used to compile all.
I'll explain.

I found that some more files needed it, or else compilation would fail.
Worse, I found that some files (well, at least one) needed it,
but without showing this by failing compilation.
The case being lib9/dirread.c : without __EXTENSIONS__ being
defined I somehow end up with a dirread that reads nothing
(could be completely my fault, by messing something up
 by playing with __EXTENSIONS__).

The point I'm trying to make is:
in this dirread case, the fact that something is broken
kind of hits you in the face as soon as you run acme,
or even plain ls: no files at all. However, there could be
a zillion things that are broken in a more subtle way.
Having to find those by stumbling over them I would find painful.

I'll probably revert u.h to its old form, and get rid of the
yield problem explicitly using the 'rename as p9yield approach'
and see where that brings me.



As a side effect of recompiling the ports world a couple
of times I got rid of another set of (silly) compiler
warnings, I'll forward these off-list to Russ after
reverting u.h, stabilizing and cleanup.

Furthermore I got the impression that the echo-disabling
code in 9term still/again needs some work: on sunos5.8
when prompting for a password, telnet succeeds to disable echo
but ssh and vncviewer fail. I did have an own version where those
worked too, I'll find time to have a look at the differences.

Another thing: I did increase some thread related stack sizes
but still saw as the end of ps output:

	sort: note: sys: child
	Abort

I'll try to get a demo purify version 
and see if that sheds some light.


Axel.



Bengt wrote:
> Richard C Bilson wrote:
> ...deleted
> > I don't know if there's a good reason for requiring __EXTENSIONS__
> > to be defined, but it didn't break anything that I can see and
> > it made the yield problem go away.
> 
> on my plan9port (plan9-20040517.tar.gz)  __EXTENSIONS__ is neccessary to 
> compile plan9/src/cmd/9term/SunOS.c . however, i think it is better to 
> defined it just for that file. obvious diff included below.
> 
> i would like to thank you for the diff to u.h. i also experimented with 
> removing __EXTENSIONS__ to get rid of sun-os yield(). however, since i 
> failed to remove the 3 #undef _NEED* after <sys/types.h> very little 
> compiled properly.
> i reinstated __EXTENSIONS__, and after that i slowly got myself totally 
> lost in various attempts to get replace yield() with p9yield(). you 
> saved me. with your change to u.h (and my change to 9term/SunOS.c) 
> everything seems to both compile and run. no changes neccessary to 
> fdwait.c, sched.c nor thread.h.
> 
> 
> bengt
> 
> *** /home/eleberg/private/plan9/src/cmd/9term/SunOS.c.original	Tue Jun 
> 15 08:42:44 2004
> --- /home/eleberg/private/plan9/src/cmd/9term/SunOS.c	Tue Jun 15 
> 08:42:46 2004
> ***************
> *** 1,4 ****
> --- 1,5 ----
>    #include <u.h>
> + #define	__EXTENSIONS__
>    #include <termios.h>
>    #include <stropts.h>
>    #include <libc.h>

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Axel Belinfante wrote:
...deleted
> I tried the 'do only define __EXTENSIONS__ where necessary approach'
> and it turned out to be pretty painful, when used to compile all.
> I'll explain.
> 
> I found that some more files needed it, or else compilation would fail.

strangely enough i only had 1 file (plan9/src/cmd/9term/SunOS.c) that 
failed to compile. perhaps you have a newer tarball than i do?


> Worse, I found that some files (well, at least one) needed it,
> but without showing this by failing compilation.
> The case being lib9/dirread.c : without __EXTENSIONS__ being
> defined I somehow end up with a dirread that reads nothing
> (could be completely my fault, by messing something up
>  by playing with __EXTENSIONS__).

this did not happen for me. ie, both ls and acme worked after 
re-compiling without __EXTENSIONS__. presumably i made a mistake somewhere.


> The point I'm trying to make is:
> in this dirread case, the fact that something is broken
> kind of hits you in the face as soon as you run acme,
> or even plain ls: no files at all. However, there could be
> a zillion things that are broken in a more subtle way.
> Having to find those by stumbling over them I would find painful.

without a test suite, things are indeed difficult.


> Furthermore I got the impression that the echo-disabling
> code in 9term still/again needs some work: on sunos5.8
> when prompting for a password, telnet succeeds to disable echo
> but ssh and vncviewer fail. I did have an own version where those
> worked too, I'll find time to have a look at the differences.
> 
sorry i do not do this. not tested.


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

Bengt wrote:
> Russ Cox wrote:
> > Fine, give up on Sun OS.

(I'm unsure whether Russ refers to the plan 9 ports,
 or to the general case of porting 'portable code' to sun os
 which was in the message he replied to, I think)

> someday i am confident that ericsson will. my part of ericsson is 
> already replacing it in the target hardware.
> perhaps the desktop is not far behind?
> until then i can live with using the ''old ports'' of plan9 programs.

here there seems to be a move from sun to (dual boot) pc+linux(+windows).
having a sun on my desk, when I have time I'm happy to have (and keep)
recent ports working -- but living with ''old ports'' is an option too
when time is lacking or problems seem too big, as I thought they were
when I started this thread.

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

> i have not experienced any name clash.
> i have not changed ''dirbuf''. i 
> do not get any bus error from ''ls''.

hmm. I guess I should do a fresh download and install,
because it could be I broke something, or let things go
out of sync (let things become inconsistent).

regarding dirbuf:
(from memory)
while playing with debugging tools like purify -
but it was another one, I think,
one loader mentioned something like changing
it(s size?) from 4 to 1000 .
I think the other dirbuf was this one:

	libnsl.a 00001000 C dirbuf
	libnsl.so 000ac9d0 B dirbuf
	libnsl.so.1 000ac9d0 B dirbuf


> an hypotetical reason for the bus error as described by you would be 
> that the real size of dirbuf is smaller than the ''book keeping size'' 
> (ndir). despite the attempt to make this possible (dirbuf gets it size 
> changes independent of the changes to ndir), there is no place in the 
> code where ndir can be bigger than the real size. as far as i can see.


Maybe the fresh install cures this as well.

As hack attempt I tried replacing the system qsort by the plan 9 one
(by including it from ls.c)
That did seem to make the problem go away.

Axel.

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

Bengt reacted 
> Axel Belinfante wrote:
> ...deleted
> > Just leaving on __EXTENSIONS__ and fixing yield in a different
> > way seems for me the easy way out.
> 
> it is not the easy way out. it is the correct way.

oops. sorry. I guess I used words that had more
meaning attached to them then necessary.
I agree with your comment; the following maybe closer
resembles what I felt when I wrote the quoted sentence above.

s/the easy way out/simplest, not necessarily least correct, solution/

whatever. I think  (hope) we (more or less?) agree, anyway :-)

Axel. (not a native speaker of english -
       does that make me native speaker of broken english?
       (which is not to be confused with english))

Re: [9fans] any success with current plan9port on sunos5.8?

[William Josephson]

On Fri, Jun 18, 2004 at 09:06:05AM +0000, Bengt Kleberg wrote:
> to plan9 yield(), but still #define NOPLAN9DEFINES.
> perhaps i have misunderstod the use of NOPLAN9DEFINES? i interpret it to 
> mean ''use the normal os version of everything that has the same name in 
> plan9''. what is the real meaning?

Don't munge the name space.  It makes system
prototypes visible; it does not dictate what
one uses.

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Axel Belinfante wrote:
>>Give up on _EXTENSIONS_ whatever that means.
>>Yield is a function provided by a system library.
>>The right fix is to rename the one the Plan 9 libraries
>>are calling.  #defining random things to make yield
>>disappear from view only makes the compiler think
>>there is no problem; it does not fix the problem.
> 
> 
> right. well put. thanks!
> done that, and seems things are ok again.
> that means, there are still a few things that fail,
> but they failed with a previous ports version in
> the same way.
> I'm sorry, but I simply do not see why or how they
> are failing, (maybe that's just because I don't know
> much about multi-threading?) so I'm posting this
> followup also to ask if someone has an explanation?
> Any insight would be appreciated.
> 
> Axel.
> 
> Details:
> 
> 
> the sort command called by ps sometimes gives me
> 'sort: note: sys: child'  followed by  Abort
> where does a SIGCHILD come from in this case? 
> (I mean, I don't see a fork; is this from some
>  thread related 'magic'?)
> 
> 
> when I do 'ls -lrt' I often get a bus error.
> it seems to be caused by an array bound read error
> in qsort (that's what purify and dbx tell me)
> but I miss to see how it is caused.
> 
> 
> In case it helps someone to understand (or explain)
> I'm including some purify output for the ls failure.
> Note: to avoid a name clash I slightly changed ls.c
> so line numbers will be off.

i have not experienced any name clash. i have not changed ''dirbuf''. i 
do not get any bus error from ''ls''.

an hypotetical reason for the bus error as described by you would be 
that the real size of dirbuf is smaller than the ''book keeping size'' 
(ndir). despite the attempt to make this possible (dirbuf gets it size 
changes independent of the changes to ndir), there is no place in the 
code where ndir can be bigger than the real size. as far as i can see.


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Axel Belinfante wrote:
...deleted
> Just leaving on __EXTENSIONS__ and fixing yield in a different
> way seems for me the easy way out.

it is not the easy way out. it is the correct way. sun-os have a 
yield(). when writing plan9port programs we want the plan9 yield().
imho, the problem is with plan9/src/libthread/fdwait.c . it has a call 
to plan9 yield(), but still #define NOPLAN9DEFINES.
perhaps i have misunderstod the use of NOPLAN9DEFINES? i interpret it to 
mean ''use the normal os version of everything that has the same name in 
plan9''. what is the real meaning?


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Russ Cox wrote:
> Give up on _EXTENSIONS_ whatever that means.

do you mean:
do not define _EXTENSIONS_
or
stop removing define _EXTENSIONS_
?
hint: the latter is correct :-)


> Yield is a function provided by a system library.
> The right fix is to rename the one the Plan 9 libraries
> are calling.  #defining random things to make yield
> disappear from view only makes the compiler think
> there is no problem; it does not fix the problem.

this is correct.

yield() is not visible in the headerfiles (unless _EXTENSIONS_ is 
defined). however, the sun linker (in my case: Solaris Link Editors: 
5.8-1.283) will make programs without _EXTENSIONS_ defined call yield() 
anyway.


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Russ Cox wrote:
> Fine, give up on Sun OS.
> 
someday i am confident that ericsson will. my part of ericsson is 
already replacing it in the target hardware.
perhaps the desktop is not far behind?
until then i can live with using the ''old ports'' of plan9 programs.


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

> Give up on _EXTENSIONS_ whatever that means.
> Yield is a function provided by a system library.
> The right fix is to rename the one the Plan 9 libraries
> are calling.  #defining random things to make yield
> disappear from view only makes the compiler think
> there is no problem; it does not fix the problem.

right. well put. thanks!
done that, and seems things are ok again.
that means, there are still a few things that fail,
but they failed with a previous ports version in
the same way.
I'm sorry, but I simply do not see why or how they
are failing, (maybe that's just because I don't know
much about multi-threading?) so I'm posting this
followup also to ask if someone has an explanation?
Any insight would be appreciated.

Axel.

Details:


the sort command called by ps sometimes gives me
'sort: note: sys: child'  followed by  Abort
where does a SIGCHILD come from in this case? 
(I mean, I don't see a fork; is this from some
 thread related 'magic'?)


when I do 'ls -lrt' I often get a bus error.
it seems to be caused by an array bound read error
in qsort (that's what purify and dbx tell me)
but I miss to see how it is caused.


In case it helps someone to understand (or explain)
I'm including some purify output for the ls failure.
Note: to avoid a name clash I slightly changed ls.c
so line numbers will be off.

Index: ls.c
===================================================================
RCS file: /cvs/plan9/src/cmd/ls.c,v
retrieving revision 1.2
diff -b -u -w -r1.2 ls.c
--- ls.c	2004/05/11 17:51:27	1.2
+++ ls.c	2004/06/17 21:06:47
@@ -2,6 +2,8 @@
 #include <libc.h>
 #include <bio.h>
 
+#define dirbuf p9dirbuf
+
 typedef struct NDir NDir;
 struct NDir
 {


****  Purify instrumented o.ls (pid 17460 at Thu Jun 17 21:44:30 2004)
  * Purify 2003a.06.00 Solaris 2 (32-bit) Copyright (C) 1992-2003 Rational Soft
ware Corp.  All rights reserved.  
  * For contact information type: "purify -help"
  * For TTY output, use the option "-windows=no"
  * Command-line: ./o.ls -lrt 
  * Options settings: -purify \
    -purify-home=/local/user/belinfan/puredemo/Rational/releases/purify.sol.200
3a.06.00 \
    -cache-dir=/local/user/belinfan/puredemo/Rational/releases/purify.sol.2003a
.06.00/cache \
    -threads=yes -use-internal-locks=yes -thread_stack_change=0x4000 \
    -mt_safe_malloc=yes -language=english 
  * License successfully checked out.
  * Command-line: ./o.ls -lrt 

****  Purify instrumented o.ls (pid 17460)  ****
ABR: Array bounds read:
  * This is occurring while in:
        compar         [ls.c:262]
        qsort          [libc.so.1]
        output         [ls.c:147]
        ls             [ls.c:122]
        p9main         [ls.c:78]
        main           [main.c:12]
  * Reading 4 bytes from 0xce190 in the heap.
  * Address 0xce190 is 8 bytes before start of malloc'd block at 0xce198 of 188
8 bytes.
  * This block was allocated from:
        malloc         [rtlib.o]
        realloc        [rtlib.o]
        growto         [ls.c:249]
        ls             [ls.c:115]
        p9main         [ls.c:78]
        main           [main.c:12]

****  Purify instrumented o.ls (pid 17460)  ****
COR: Fatal core dump:
  * This is occurring while in:
        _p1553static   [rtlib.o]
        _p1243static   [rtlib.o]
        compar         [ls.c:269]
        qsort          [libc.so.1]
  * Received signal 11 (SIGSEGV - Segmentation Fault)
  * Faulting address = 0xffbf0000
  * Signal mask: (SIGSEGV) 
  * Pending signals: 


dbx output of a similar crash (but different run):

(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx) run -lrt
Running: o.ls -lrt 
(process id 18217)
t@1 (l@1) signal BUS (invalid address alignment) in compar at line 269 in file "ls.c"
  269   			i = bd->mtime-ad->mtime;
(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx) up
0xff14b7ec: qsort+0x010c:	jmpl    %i5, %o7
(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx) up
Current function is output
  147   		qsort(dirbuf, ndir, sizeof dirbuf[0], (int (*)(const void*, const void*))compar);
(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx) where
current thread: t@1
  [1] compar(a = 0x48b98, b = 0x48ba8), line 269 in "ls.c"
  [2] qsort(0x48ba8, 0x8, 0x48b98, 0x48c10, 0x49318, 0x187f8), at 0xff14b7ec
=>[3] output(), line 147 in "ls.c"
  [4] ls(s = 0x3dd50 ".", multi = 0), line 122 in "ls.c"
  [5] p9main(argc = 0, argv = 0xffbec864), line 78 in "ls.c"
  [6] main(0x2, 0xffbec85c, 0xffbec868, 0x3d000, 0x0, 0x0), at 0x1aec8
(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx) print ndirbuf
ndirbuf = 239
(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx) print ndir
ndir = 239
(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx)

Re: [9fans] any success with current plan9port on sunos5.8?

[Russ Cox]

Fine, give up on Sun OS.

Russ

Re: [9fans] any success with current plan9port on sunos5.8?

[Lyndon Nerenberg]

It's pretty much impossible to compile any portable code on Solaris 
without defining __EXTENSIONS__. We used to modify our copies of 
Solaris gcc to define it by default. The alternative was an awful lot 
of hacking on Makefiles.

--lyndon

Re: [9fans] any success with current plan9port on sunos5.8?

[Russ Cox]

Give up on _EXTENSIONS_ whatever that means.
Yield is a function provided by a system library.
The right fix is to rename the one the Plan 9 libraries
are calling.  #defining random things to make yield
disappear from view only makes the compiler think
there is no problem; it does not fix the problem.

Russ

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

> > The point I'm trying to make is:
> > in this dirread case, the fact that something is broken
> > kind of hits you in the face as soon as you run acme,
> > or even plain ls: no files at all. However, there could be
> > a zillion things that are broken in a more subtle way.
> > Having to find those by stumbling over them I would find painful.
> 
> I'm not sure I agree.  The code hasn't been in use long enough to
> convince me that it isn't broken in subtle ways, even with _EXTENSIONS_
> enabled.  And my experience in trying to write portable code on
> UNIX-ish systems has led to a deep distrust of feature-test macros.
> But you're the one doing the work (at least, right now), and if you
> can make it work then more power to you.

Ok. I see your point. Let me try to phrase be a bit more accurately.
what I basically meant was:

with a previous ports release (where the yield problem was not present)
things (at least those that I tried, used) were working more or less ok.

Now I tried to get rid of the yield problem by playing with
the __EXTENSIONS__ macro, and it seems that there are places where
it is really necessary -- but the compiler does not help to
find all of those, for some (at least one) you only notice
the need because programs behave in a different way.
For me that means, to have reasobly trust in the result,
I either have to know what I am doing (I don't), or test all
programs to a certain extent. That seems tough
Just leaving on __EXTENSIONS__ and fixing yield in a different
way seems for me the easy way out.
Don't know if it is the best way, but for me, with no knowledge
whatsoever about where __EXTENSIONS__ is needed and where not
(apart from what I learned by trying to get things working),
it really seems for me the easiest, and the one giving me the most
reliable result.
Someone in know about all this surely can do a better job,
but, I guess for me it boils down to:
if it ain't broke, don't fix it
(or: only fix the small thing that you see breaking,
 but avoid touching those (scary) bits that
 (for all I can tell, seem to) work)

Axel.

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

> From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
> 
> The point I'm trying to make is:
> in this dirread case, the fact that something is broken
> kind of hits you in the face as soon as you run acme,
> or even plain ls: no files at all. However, there could be
> a zillion things that are broken in a more subtle way.
> Having to find those by stumbling over them I would find painful.

I'm not sure I agree.  The code hasn't been in use long enough to
convince me that it isn't broken in subtle ways, even with _EXTENSIONS_
enabled.  And my experience in trying to write portable code on
UNIX-ish systems has led to a deep distrust of feature-test macros.
But you're the one doing the work (at least, right now), and if you
can make it work then more power to you.

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Axel Belinfante wrote:
...deleted
> Just to make sure you do not have the same problem as I had:
> check which *yield* symbols are present in your non-working binary,

i have both p9yield and yield present.


...deleted
> Fix it by recompiling fdwait.c such that the yield() call
> in that file gets #define'ed to p9yield, so there is no
> reference any more to the sunos system library yield routine.

will do.


...deleted
>>int	p9yield(void);
>>#ifndef NOPLAN9DEFINES
>>#define       yield   p9yield
>>#endif
>>
> 
> 
> Looking at it now, I guess a different (better?!?) solution might be
> to simply remove the #ifndef NOPLAN9DEFINES and #endif lines from
> around above #define in thread.h .

imho the idea of NOPLAN9DEFINES is to make sure that only the original 
operating systems definitions are present. it would be very confusing to 
  get yield() replaced with p9yield() after having defined NOPLAN9DEFINES.

your first idea is better. however, i do not think it is perfect. 
instead, i wonder why fdwait.c had NOPLAN9DEFINE. if it was neccessary 
surely something else is now broken when it was removed. and if it was 
not neccessary, why was it there?


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

> From: Charles Forsyth <forsyth@terzarima.net>
> 
> __EXTENSIONS__ is possibly needed if you use unistd.h and want the i/o calls to be 64 bit.
> that's seems to be the easiest way to get the right combination
> with Solaris 2.6.  see /usr/include/unistd.h for an example of how not to do it.

Well, scanning through the 2.8 (5.8? 8?) version of unistd.h, it seems
like they fixed this.  Perhaps I'm just being optimistic, however.

> specifically, on some systems including that version of Solaris the `feature' macro definitions
> are feature disablers more than feature enablers.

They are certainly productivity disablers.

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

> From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
> 
> Hmmm... is there a p9yield in the linked (e.g.acme) executable?
> maybe your libthread yield is also unaffected (not renamed to p9yield)?

Upon further inspection this does indeed seem to be the case.

Aside from my previously-posted change to mainstacksize, I'm using a
virgin libthread.  I can't explain why it works for me and not for
others, but I'm happy to provide whatever assistance I can off-list to
anyone trying to get it working.

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

> > in the same way, try (typing path from memory)
> > 
> > 	nm $PLAN9/src/libthread/fdwait.o | grep yield
> 
> What's interesting is that, on my working system, I get
> 
> [40]	|         0|       0|NOTY |GLOB |0    |UNDEF  |yield
> 
> which, presumably, is *not* the way it's supposed to be (i.e.,
> I ought to be seeing "p9yield" instead).

Hmmm... is there a p9yield in the linked (e.g.acme) executable?
maybe your libthread yield is also unaffected (not renamed to p9yield)?

Axel.

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

> From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
> 
> in the same way, try (typing path from memory)
> 
> 	nm $PLAN9/src/libthread/fdwait.o | grep yield

What's interesting is that, on my working system, I get

[40]	|         0|       0|NOTY |GLOB |0    |UNDEF  |yield

which, presumably, is *not* the way it's supposed to be (i.e.,
I ought to be seeing "p9yield" instead).

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

Bengt wrote:
> Richard C Bilson wrote:
> 
> > Well, I had to comment out some stuff that doesn't work and rename a
> > few symbols, but in large part it works.  I believe Bengt already
> > described most of these problems.  I'm typing this in acme right now.
> > 
> 
> it has to be added that i only got things to compile. i can not get the 
> graphical programs (sam, acme, 9term) to work. the window appears, but 
> there is no content. a working acme is much better result than i 
> managed. congratulations.

Just to make sure you do not have the same problem as I had:
check which *yield* symbols are present in your non-working binary,
do something like

	nm o.acme |grep yield

If you have both p9yield and yield you likely have the same problem.
in the same way, try (typing path from memory)

	nm $PLAN9/src/libthread/fdwait.o | grep yield

that is where my problem originated.
Fix it by recompiling fdwait.c such that the yield() call
in that file gets #define'ed to p9yield, so there is no
reference any more to the sunos system library yield routine.

My fix was:

; cvs diff fdwait.c
Index: fdwait.c
===================================================================
RCS file: /cvs/plan9/src/libthread/fdwait.c,v
retrieving revision 1.8
diff -r1.8 fdwait.c
1c1
< #define NOPLAN9DEFINES
---
> //#define NOPLAN9DEFINES

This is to make sure that the following workaround to
deal with the yield name clash has the right effect.

Index: thread.h
===================================================================
RCS file: /cvs/plan9/include/thread.h,v
retrieving revision 1.9
diff -r1.9 thread.h
124c124,128
< int	yield(void);
---
> int	p9yield(void);
> #ifndef NOPLAN9DEFINES
> #define       yield   p9yield
> #endif
> 

Looking at it now, I guess a different (better?!?) solution might be
to simply remove the #ifndef NOPLAN9DEFINES and #endif lines from
around above #define in thread.h .

Axel.

Re: [9fans] any success with current plan9port on sunos5.8?

[Bengt Kleberg]

Richard C Bilson wrote:

> Well, I had to comment out some stuff that doesn't work and rename a
> few symbols, but in large part it works.  I believe Bengt already
> described most of these problems.  I'm typing this in acme right now.
> 

it has to be added that i only got things to compile. i can not get the 
graphical programs (sam, acme, 9term) to work. the window appears, but 
there is no content. a working acme is much better result than i 
managed. congratulations.


bengt

Re: [9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

> Well, I had to comment out some stuff that doesn't work and rename a
> few symbols, but in large part it works.  I believe Bengt already
> described most of these problems.  I'm typing this in acme right now.

Cool. Looked back at Bengt's message, and reread the (p9)yield fix,
which I remembered applying.
Then found that my libthread/fdwait.c starts (started, by now)
with a #define NONOPLAN9DEFINES such that my pollidle would call
sunos' yield() instead of libthreads (renamed via the #define) p9yield() :-(
(why I did add the NONOPLAN9DEFINES there I don't recall)

Suffices to say that after some recompilations acme now works,
and I'm pretty confident that after recompiling
(after removing all the debug prints I introduced)
the whole port will benefit from the increased stack sizes.

Thanks _a_lot_ for the replies to my initial post in this thread,
which gave me enough inspiration to put in enough perspiration...

Axel - feeling foolish, but happy it works now

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

> From: C H Forsyth <forsyth@vitanuova.com>
> 
> ---
> > #define	STACK	65536
> ===================================================================
> ---
> > 		mainstacksize = 64*1024;
> 
> 
> what are they doing that uses that much??

Well, like I said, I may be (and probably am) overprovisioning my
stacks.  But I know that you can't go too far below 32k and expect
anything to work.  For one thing, every stack frame needs to reserve
space to spill an entire register window (96 bytes), plus locals, plus
arguments that don't fit in registers.  For another thing, some of the
call stacks in X are ridiculously deep.

Re: [9fans] any success with current plan9port on sunos5.8?

[Russ Cox]

> Maybe they're as clever as the GNU folks
> and use a ton of stack space to do qsort().

Now, now.  The only reason the GNU folks 
use a lot of stack space for qsort() is the big
buffer that they read /proc/meminfo into.
The sort itself is very careful about how much
stack it uses.

Russ

Re: [9fans] any success with current plan9port on sunos5.8?

[C H Forsyth]

---
> #define	STACK	65536
===================================================================
---
> 		mainstacksize = 64*1024;


what are they doing that uses that much??

Re: [9fans] any success with current plan9port on sunos5.8?

[William Josephson]

On Fri, Jun 11, 2004 at 03:02:04PM +0100, C H Forsyth wrote:
> ---
> > #define	STACK	65536
> ===================================================================
> ---
> > 		mainstacksize = 64*1024;
> 
> 
> what are they doing that uses that much??

Maybe they're as clever as the GNU folks
and use a ton of stack space to do qsort().

Re: [9fans] any success with current plan9port on sunos5.8?

[Richard C Bilson]

> From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
> 
> Just curious: has anyone had any luck with the
> current plan9 ports package on sunos 5.8?
> (I read that Bengt has problems too, and that
>  for Russ it works (fine?) on 5.9, correct?)

Well, I had to comment out some stuff that doesn't work and rename a
few symbols, but in large part it works.  I believe Bengt already
described most of these problems.  I'm typing this in acme right now.

I do notice that among my diffs that at one point I played with the
stack size.  I don't know whether a larger stack is actually necessary,
but I do know that most of the SunOS problems I've had have come down
to one stack or another being too small.

Index: cmd/acme/dat.h
===================================================================
RCS file: /cvs/plan9/src/cmd/acme/dat.h,v
retrieving revision 1.7
diff -r1.7 dat.h
549c549
< #define	STACK	32768
---
> #define	STACK	65536
Index: libthread/main.c
===================================================================
RCS file: /cvs/plan9/src/libthread/main.c,v
retrieving revision 1.9
diff -r1.9 main.c
47c47
< 		mainstacksize = 32*1024;
---
> 		mainstacksize = 64*1024;

[9fans] any success with current plan9port on sunos5.8?

[Axel Belinfante]

Just curious: has anyone had any luck with the
current plan9 ports package on sunos 5.8?
(I read that Bengt has problems too, and that
 for Russ it works (fine?) on 5.9, correct?)

I tried to investigate why for me acme hangs,
and right now I have the impression that it
somehow hangs in the connection to the plumber.

In more detail: I'm getting the impression that
maybe the 'connection' between 9pserve and the
plumber that starts it is not working for me.
While I'm digging, maybe someone knows: could
the changes between the current ports version,
and the version of say a month earlier explain
that?

Axel - just continues digging