[9fans] some pcc questions

[Jens Staal]

Hi all

I have some problems that I sometimes run into while trying to port
stuff. One is that some files just "freezes" the compilation process
(but load goes down to 0 so it is not just labour intensive, but
rather that it just "sticks" there without doing anything) and when I
exit the compilation (by pressing "delete") I get different error
messages every time.

Is there a way to track down what is really happening in those cases
in order to solve them?


The second issue that I have been meaning to ask the list is about pcc
and bitfields - are they supported or is this some sort of can of
worms I have stepped into?

Here I have a more specific issue with compiling GNU m4: Compiling the
gnulib and all other files except src/builtin.c works fine with APE
libs and pcc, but builtin.c fails due to bitfields.
At the other side of the spectrum, a modern GNU m4 (including
src/builtin.c) can be compiled with the old GCC port, but there the
GCC-ported APE-libs are too old (vsnprintf etc not supported), so it
fails at the final linking phase since lots of stuff are not provided
by the C library.

Personally, I would prefer to crack that particular nut with pcc than
to go for an updated APE libs port to GCC so if there are specific
changes that can be done to bitfields in order to get it working, it
would be very interesting to hear about them...

some more details on why I even would bother doing such a thing:
http://code.google.com/p/ports2plan9/wiki/GNUonPlan9

[c***@gmx.de]

Attach: /rc/bin/tap

if something hangs, theres a good opportunity to figure
out what is happening by looking in what state the
various processes of the horde are using acid or acid -k.

this does require knowledge of wich process waits for whom.

for simple await() relationship, it is easy. there are
various pstree programs arround for plan9.

for process pipelines, i'v written the program tap (attached
to this mail) that walks the filedescriptor table of a
process, checks for a pipe and then searches /proc for other
processes having the other end of that pipe open doing this
recursively.

deadlocked fileservers are harder to track down.

if these hang conditions are reproducable, you might also try
stuff like rons ratrace.

good luck :)

--
cinap

[c***@gmx.de]

that attachment didnt quite work, lets try it this way :)

--
cinap

[Charles Forsyth]

cute.

Post by c***@gmx.de
for process pipelines, i'v written the program tap

[Jens Staal]

Post by Jens Staal
The second issue that I have been meaning to ask the list is about pcc
and bitfields - are they supported or is this some sort of can of
worms I have stepped into?

I have just hit another "pcc can not initialize bitfields" problem
with netsurf libcss. If anyone know how to tackle that issue (or if it
even CAN be tackled) it would be greatly appreciated.
The broken build of libcss can be found either at
/n/sources/contrib/staal1978/pkg/libcss-alpha1.tbz or [1].

[1] http://code.google.com/p/ports2plan9/downloads/detail?name=libcss-alpha1.tbz

I hope by solving this issue I might be able to make a native APE
build of GNU m4 pretty easily afterwards if the bitfield issue is the
same ;)

[Comeau At9Fans]

Post by Jens Staal
I have just hit another "pcc can not initialize bitfields" problem
with netsurf libcss. If anyone know how to tackle that issue (or if it
even CAN be tackled) it would be greatly appreciated....

From what I recall, it comes up when a bitfield is nested inside a struct,
and in particular the default initialization to 0 is attempted. There may
be other cases as well. It may have only been an issue at file scope too,
can't recall exactly.

[Comeau At9Fans]

Post by Jens Staal
The second issue that I have been meaning to ask the list is about pcc
and bitfields - are they supported or is this some sort of can of
worms I have stepped into?

Bitfields are allowed to have lots of *-defined behavior, so often they are
cans of worms on many platforms. Don't know if you're referring to this
kind of issue or something more specific that you might feel is a
limitation on Plan 9.

[erik quanstrom]

Post by Comeau At9Fans

Post by Jens Staal
The second issue that I have been meaning to ask the list is about pcc
and bitfields - are they supported or is this some sort of can of
worms I have stepped into?

Bitfields are allowed to have lots of *-defined behavior, so often they are
cans of worms on many platforms. Don't know if you're referring to this
kind of issue or something more specific that you might feel is a
limitation on Plan 9.

crazy idea i haven't tried.

why not use X in sam or acme to mass-edit fu:bar -> fu[bar] and just make
fu an array.

- erik

[Bakul Shah]

Post by erik quanstrom
crazy idea i haven't tried.
why not use X in sam or acme to mass-edit fu:bar -> fu[bar] and just make
fu an array.

? How will that work for something like
struct X {int a:5, :8, c:12,:7; float d;} x;
Usually you can convert bitfields ops to operations under masked -- what the compiler has to do. So reading x.c becomes ((x.i>>7)&0xfff) etc. Where x.i represents the same word where a &c are stored. I thought that (except for pcc) bitfields code gen & performance issues got fixed a long time ago?