jkp@sauna.hut.fi (Jyrki Kuoppala) (03/07/91)
In article <m0jE1SY-0003MoC@meepmeep.pcs.com> Jordan writes: >Do you need to remake all the /bin utilities when you recompile the >kernel with GNU gcc 1.39? Well, if you use the diff currently on nic.funet.fi for gcc 1.39, it's a good idea, otherwise many of the binaries will fail because struct stat is incompatible, for example. But I could use the small-alignment login and init on the large-alignment kernel just fine. Of course, if you haven't got the courage to move to the ns32k standard alignment ;-) you can just continue to use the old alignment, #undef BIGGEST_ALIGNMENT and #define it to 16 in the tm.h file. But beware: then you have results like Jordan had, cc1 will loop in insn-recog.o when insn-recog.c is compiled with -O and assembled with gas 1.38.1 compiled with 16-bit structure alignment, no matter if that gas is compiled with GNU or Bruce tools (I think). You'll also get core dumps from gas compiling dbxread.c and regex.c from gdb 3.5 with -O. Confused yet ? Well, I have more .. Apparently Bruce's tools don't work with 32-bit alignment, the linker dumps core on me (I have recompiled the binaries and libraries with the new alignment). Well, you can't win them all .. About gas bugs: after using the kludge fix from me, you can use PC_RELATIVE with my gcc 1.39 diff (uncomment the last line in tm-pc532.h in my latest gcc-1.39 distribution). >Last night, after some pain, I managed to get the GNU (that is - GAS/GLD) >version of 1.39 to actually compile hello_world.c without looping forever >in cc1. Yea! Says I. Then I recompile the kernel, using Jyrki's GAS versions >of the relevant .s files. Kernel comes up, prints a bizarre date, then >panics because it can't find init. I don't pretend to understand all aspects >of the alignment debate as it pertains to Minix (I suppose I should learn), >but I still don't see why it would cause this should happen. What would? Hmm, did you recompile the libraries with the new compiler before recompiling the kernel ? I don't know which routines the kernel uses from libc.a, but I think some, so this could matter. >At this point, I have 5 different versions of Minix 1.3, 1.5 and 1.3/1.5 >on my disk, all patched subtly differently. Hey, that's as many as there are different print_operand_address functions for ns32k gcc ;-) >1. Get Bruce's tools up to 1.39, and the hybrid up to the last Phil > Nelson patch level. If you use Bruce's tools and want to use the old alignment (well, I suppose you have to if Bruce's tools fail with 32-bit alignment) all you have to do is to redefine BIGGEST_ALIGNMENT to 16, say ./config.gcc pc532-wbc to gcc 1.39 patched with my current diffs from nic.funet.fi, say 'make' and go your merry way. Phil Nelson's first 1.5.10 hybrid should be quite good as a starting point - well, I don't know about the compiler, I didn't use that, but I hear it works. I didn't have to make any changes to the kernel / libs to get it running. But after that, I have converted to gas syntax with the kernel & libraries assembly files, gcc 1.39 with GNU tools & bigger alignment and recompiled about all the Minix binaries and lots of other free (GNU & others) software with the gcc 1.39 with big alignment. Also I use 62-character file names, Jordan's fch{own,mod}, ptrace support, bumped up many constants and I think some minor things. I've had no trouble after fixing the gas bug and moving to bigger alignment, so I suppose I can recommend gcc 1.39 and gas 1.38.1 with my patches, though I still feel kindof uncomfortable with gas. But I have compiled my kernel, libs, gcc, gdb, GNU *utils, Minix /usr/bin and all others with that combination, so it can't have that many bugs anymore. But as always, booting it all up is kind of a problem (moving to 32-bit alignment was not that simple, esp. with only 64 Meg disk space which is supposed to hold all the sources & binaries to Minix, gcc, gdb, gas, emacs, g++, and many many other programs). Well, you win some, you lose some. >1. All system hacks (this includes the libraries + includes) go to > Phil & Bruce. If they are going out of action for awhile, perhaps > they should appoint someone to guest-coordinate for awhile in their > stead. No system patches go to the list. Period. Well, it's a bit of a problem because I don't suppose all want to use gas, even I don't yet trust it totally even though it seems to work with my kludge-patch and 32-bit alignment. And then, until Bruce tools are working with 32-bit alignment you lose an important comparison environment - to compare if a program works with GNU tools and/or Bruce tools. My other kernel & lib changes which I have thought are kosher enough I have sent to the list. Also, distributing the kernel / library with two different sets of assembly files is painful. I can't think of a good solution for this. By the way, I now have g++ 1.39.0 running. Not that sure if it works because I don't yet have libg++. I'll release diffs later. //Jyrki
jkh@meepmeep.pcs.com (Jordan K. Hubbard) (03/07/91)
Do you need to remake all the /bin utilities when you recompile the
kernel with GNU gcc 1.39?
Last night, after some pain, I managed to get the GNU (that is - GAS/GLD)
version of 1.39 to actually compile hello_world.c without looping forever
in cc1. Yea! Says I. Then I recompile the kernel, using Jyrki's GAS versions
of the relevant .s files. Kernel comes up, prints a bizarre date, then
panics because it can't find init. I don't pretend to understand all aspects
of the alignment debate as it pertains to Minix (I suppose I should learn),
but I still don't see why it would cause this should happen. What would?
At this point, I have 5 different versions of Minix 1.3, 1.5 and 1.3/1.5
on my disk, all patched subtly differently. To say that I am having a hard
time keeping it straight after 3am is an understatement. Tonite, I will
take a blowtorch to my disk (the figurative kind, of course) and start
from scratch with the vanilla 1.3/1.5 hybrid release and Bruce's tools.
Sigh. Unless we can get some greater sense of Minix unity here, I'm
going to do the following in the post-nuke phase:
1. Get Bruce's tools up to 1.39, and the hybrid up to the last Phil
Nelson patch level.
2. STOP. No GNU gcc, no estdio, no GDB, no nothing that isn't blessed
by Bruce and Phil.
I have no problem with doing the extra work, it's just that when I
tried going my own way before, I would constantly find duplicates of
my efforts the next morning in my mailbox!
May I respectfully point out the following:
In the beginning days of the pc532, all was fine and dandy with everyone
happily spinning their own little independent development threads. Since
most everything was stand-alone, there wasn't much of anything to standardise
on anyway so it didn't much matter. I did a little bit to help by releasing
the libraries, but it was just a stopgap measure and not of much permanant
use.
Now a good percentage (?) of us are running one OS, for better or worse.
This environment is just complex enough that not everyone has the time
or motivation to become a Minix Expert, nor should they, necessarily.
Why? Well, there are enough independent little bits of Minix that need
improving that we stand to gain the most by directing people's efforts
in as many different directions as we can. Having 4 or 5 "total gurus"
whacking on the same bits of code, without much (perceived)
coordination, doesn't do the overall effort much good at all. It can
also lead only to frustration in those who have chosen to "follow"
rather than "lead" in the Minix parade. I, for one, would be happy
enough to "follow" if given a clear enough path. So far, the patches
from Bruce and Phil have seemed well-coordinated and I have quite a
bit of faith in them. I would be happy enough at this point just
following their lead and expending my efforts in other, more needed,
areas. For example, the last two weeks I've wanted to spend my time
working on improving fs performance, but haven't gotten even so much
as a start on it due to being solidly tied up trying to untangle the
job of porting gcc+estdio+latest kernel hacks + assorted gnu utilitys.
This frustrates me and doesn't give the rest of you better fs
performance.
I'm not knocking Jyrki or Sverre's (Hi Jyrki!) efforts at all here,
don't get me wrong, I just think (in my usual verbose and rambling fashion
:-) that a better way of coordinating all this needs to be worked out.
How about something like the following?
1. All system hacks (this includes the libraries + includes) go to
Phil & Bruce. If they are going out of action for awhile, perhaps
they should appoint someone to guest-coordinate for awhile in their
stead. No system patches go to the list. Period.
2. Porting of GNU software and other interesting applications goes to
Jyrki. He figures out some decent scheme for releasing diffs (which,
BTW, have been top-notch so far, so YOU'RE IT JYRKI! :-). If anyone
else ports something cute, they send the diffs to him. I think diffs
could also be sent to the list, since ancillary utilities aren't so
critical to decent system operation.
3. A minix mailing list is set up for those who want to discuss trends
and ideas ("should we add the symlink code? Why not?") + tips for
doing weird things like going to 62 character file names.
4. I stop whining, get my system back in stable condition again, and go
back to working on the stuff I was supposed to be doing instead!
Jordanculberts@hplwbc.hpl.hp.com (Bruce Culbertson) (03/08/91)
> Apparently Bruce's tools don't work with 32-bit alignment, the linker > dumps core on me (I have recompiled the binaries and libraries with > the new alignment). Well, you can't win them all .. Unfortunately, this is true. My tools commit the portability crime of reading from a file directly into an array of struct's. Instead, they should read the file as a byte stream and repackage the bytes into the array of struct's. Actually, if you recompile EVERYTHING, then my tools should continue to work, but the a.out format will be different than before, e.g., a symbol table struct becomes 12 bytes instead of the current 10 bytes. This means, for example, you could not use your old libc.a while linking with the new linker. I really ought to fix this. My intention is that the a.out format should stay the same, regardless of what compiler you use to compile my assembler and linker. > 1. All system hacks (this includes the libraries + includes) go to > Phil & Bruce. If they are going out of action for awhile, perhaps > they should appoint someone to guest-coordinate for awhile in their > stead. No system patches go to the list. Period. I would be happy to help coordinate the system hacking. I am in favor of having coordinators for various aspects of the system. Bruce