HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (01/30/91)
Recently there was a posting which stated the need for a unified GNU port. The extensive hacking on GNU which was done in the past is obsolete now because - MINIX 1.5 has removed some deficiencies of MINIX 1.1 - The GNU version which was taken is replaced by a newer version. Personally, I am most interested in GNU as, ar, ld, cpp to make a compiling system together with c68/c386 (GNU cc is much too large for me). The main problem for me are the incompatible format of the system binaries, this has resulted in an extensive hack to ld once. My question, would it be tolerable to use the originial GNU a.out format and design a conversion program that converts GNU binaries to MINIX binaries (yes I hear you crying: ''we have just overcome that odd cv program'') -- in a later step, it might be possible to modify MM such that it can load GNU binaries [ I know that the GEM reloaction info is more dense than the reloc info produced with ld -r ]. This would free us from the need to hack every new version of GNU ld as it comes along. I would personlly prefer to make as few changes as possible. I will look if the bug in m68k.md which I reported to R. Stallman is removed in gcc 1.39. If so, I will post a 20-line patch which makes sizeof() yielding a 16-bit int in -mshort mode (I think this is the main reason why GCC does not work with all MINIX-1.5 sources, at least in fdopen(), there is ..... = malloc(sizeof(...)); which does not work with an un-modified gcc since size_t is long or unsigned long (depending on flag_traditional) there. C.v.W.
wayne@csri.toronto.edu (Wayne Hayes) (01/30/91)
In article <43079@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >My question, would it be tolerable to use the originial GNU a.out format and >design a conversion program that converts GNU binaries to MINIX binaries Sorry to disappoint you, but this has already been done. I've forgotten where I got it, but I have gcc up and running on my Minix-386 box, and it produces a non-Minix a.out which is converted to Minix via a program called, oddly enough, 'gcc2minix'. It works fine when you put a nice front end shell script onto it that calls gcc and then gcc2minix. -- "Dad, what should I be when I grow up?" "Honest." -- Robert M. Pirsig, _Zen and the Art of Motorcycle Maintenence_. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (01/30/91)
In article <43079@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > Recently there was a posting which stated the need for a unified GNU > port. (stuff deleted) > My question, would it be tolerable to use the originial GNU a.out format and > design a conversion program that converts GNU binaries to MINIX binaries > (yes I hear you crying: ''we have just overcome that odd cv program'') -- > in a later step, it might be possible to modify MM such that it can load > GNU binaries [ I know that the GEM reloaction info is more dense than > the reloc info produced with ld -r ]. (more stuff deleted) > C.v.W. As the poster of the "unified gcc" article, I agree entirely with your comments. The whole problem revolves round the question of the ACK a.out as against the gnu a.out. This is mainly what I was enquiring about when I asked gcc porters to contact me. I have so far seen the following approaches to the solution: 1. Patch gcc-ld, as per bammi's original idea. This is fine until a new version of gcc-ld comes along (as it already has). 2. Add an entirely separate conversion program, as Alan Black did for the 386. This is nice and simple, and does not require alterations to gcc-ld. Unfortunately it also means adding extra lines to every Makefile in existence. 3. Incorporate the gcc-to-minix conversion as an extra stage in gcc-ld. I have already done this for the 386, and it involves minimal changes to gcc-ld, which should be easily portable to newer versions since the conversion code is merely pulled in as a separate file. 4. Get MINIX to load gnu a.out format directly. Alan Black recently implemented this for the 386, but the 68k's need relocation info as well. I would like to see a solution which works for both 386 and 68k, and the 68k would need more work to cope with the gnu relocation info. 5. Bruce Evans has an approach using macros in a.out.h, which I regard as a sort of half-way house. Again this is only for the 386 rather than 68k. I personally feel that the best idea is to get MINIX to accept gnu format programs, so that gnu utilities such as gdb will work without further hacking. However approach 3 above is probably the simplest, and will work on both 68k and 386 without too much difficulty. Comments anyone ? Regards Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) "You might think that. I 85 Hawthorne Crescent couldn't possibly comment." West Drayton Middlesex UB7 9PA
adrie@philica.ica.philips.nl (Adrie Koolen) (02/01/91)
In article <1991Jan29.234455.10126@jarvis.csri.toronto.edu> wayne@csri.toronto.edu (Wayne Hayes) writes: >In article <43079@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >>My question, would it be tolerable to use the originial GNU a.out format and >>design a conversion program that converts GNU binaries to MINIX binaries > >Sorry to disappoint you, but this has already been done. I've forgotten >where I got it, but I have gcc up and running on my Minix-386 box, and >it produces a non-Minix a.out which is converted to Minix via a program >called, oddly enough, 'gcc2minix'. It works fine when you put a nice >front end shell script onto it that calls gcc and then gcc2minix. There's a handier way to do this. For Minix-Sparc, the GNU C compiler also generates an a.out file with a GNU header (which is in fact a SunOS compatible executable file header). I adopted the compiler dispatcher, gcc.c, to call a conversion program, cv in my case, to change the header and the symbol table to the Minix format. You only have to fiddle with link_spec to call your conversion program at the end. If your interested, I can mail the cdiff file against gcc.c of 1.37.1, it's some 40 lines. I guess, that other persons, who ported GNU C to Minix-386 did the same thing, as this the way to do it. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (02/02/91)
In article <739@philica.ica.philips.nl>, adrie@philica.ica.philips.nl (Adrie Koolen) writes: > In article <1991Jan29.234455.10126@jarvis.csri.toronto.edu> wayne@csri.toronto.edu (Wayne Hayes) writes: > >In article <43079@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > >>My question, would it be tolerable to use the originial GNU a.out format and > >>design a conversion program that converts GNU binaries to MINIX binaries (stuff deleted) > There's a handier way to do this. For Minix-Sparc, the GNU C compiler also > generates an a.out file with a GNU header (which is in fact a SunOS compatible > executable file header). I adopted the compiler dispatcher, gcc.c, to call > a conversion program, cv in my case, to change the header and the symbol > table to the Minix format. You only have to fiddle with link_spec to call > your conversion program at the end. If your interested, I can mail the cdiff > file against gcc.c of 1.37.1, it's some 40 lines. I guess, that other persons, > who ported GNU C to Minix-386 did the same thing, as this the way to do it. > > Adrie Koolen (adrie@ica.philips.nl) > Philips Innovation Centre Aachen I thought about doing it this way and decided to alter gcc-ld instead, for two main reasons. Firstly, on a conceptual basis, the job of the linker is to take object files and turn them into a running executable. There are several Makefiles in MINIX and elsewhere which assume that calling the linker on its own will produce a workable output. I suggest that it is entirely reasonable to expect this to work. Altering gcc.c won't have that effect. Secondly, patching gcc.c is not easy. It's pretty awkward to keep track of the existing link-spec code without making it even more difficult. On the other hand, gcc-ld consists of lines like do_something(); do_something_else(); which make it extremely easy to add a three line patch #ifdef MINIX do_convert(); #endif The conversion routines themselves live in separate files which are totally independent of gcc-ld, thereby "future-proofing" them against changes in gcc-ld itself. I must admit that I still have a leaning towards Alan Black's idea of getting MINIX to understand GNU format a.out directly. His solution of the chmem problem is pretty neat as well. However I do wonder what happens if MINIX includes <a.out.h.gnu> - does it then get covered by the copyleft ??? Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) "You might think that. I 85 Hawthorne Crescent couldn't possibly comment." West Drayton Middlesex UB7 9PA
wayne@csri.toronto.edu (Wayne Hayes) (02/02/91)
In article <1974@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >2. Add an entirely separate conversion program, as Alan Black did for the >386. This is nice and simple, and does not require alterations to gcc-ld. >Unfortunately it also means adding extra lines to every Makefile in >existence. NO! This isn't necessary. I wrote a little shell script called "gcc", renamed the real gcc to gcc-exec, and the shell script does the conversion after the real compile is finished. It's so short I include it here in both clear text and uuencoded. --- snip snip --- #!/bin/sh gcc-exec $* case $? in 0) ;; *) exit 1;; esac out="a.out" c="" while test -n "$1"; do case "$1" in -o) out="$2"; shift ;; -c) exit 0 ;; # no executable generated *) ;; esac shift done gcc2minix <$out >gcc$$ mv gcc$$ $out exec chmod +x $out --- snip snip --- begin 644 gcc.sh M(R$O8FEN+W-H"@IG8V,M97AE8R`D*@IC87-E("0_(&EN"@DP*0D[.PH)*BD@ M(&5X:70@,3L["F5S86,*"F]U=#TB82YO=70B"F,](B(*=VAI;&4@=&5S="`M M;B`B)#$B.R!D;PH)8V%S92`B)#$B(&EN"@D)+6\I(&]U=#TB)#(B(#L["@D) M+6,I(&5X:70@,"`[.PDC(&YO(&5X96-U=&%B;&4@9V5N97)A=&5D"@D)*BD@ M.SL*"65S86,*"7-H:69T"F1O;F4)"F=C8S)M:6YI>"`\)&]U="`^9V-C)"0* A;78@9V-C)"0@)&]U=`IE>&5C(&-H;6]D("MX("1O=70* ` end -- "Dad, what should I be when I grow up?" "Honest." -- Robert M. Pirsig, _Zen and the Art of Motorcycle Maintenence_. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525
adrie@philica.ica.philips.nl (Adrie Koolen) (02/04/91)
In article <1985@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >In article <739@philica.ica.philips.nl>, adrie@philica.ica.philips.nl (Adrie Koolen) writes: >> I adopted the compiler dispatcher, gcc.c, to call >> a conversion program, cv in my case, to change the header and the symbol >> table to the Minix format. You only have to fiddle with link_spec to call >> your conversion program at the end. >I thought about doing it this way and decided to alter gcc-ld instead, for two >main reasons. > >Firstly, on a conceptual basis, the job of the linker is to take object files >and turn them into a running executable. There are several Makefiles in MINIX >and elsewhere which assume that calling the linker on its own will produce a >workable output. I suggest that it is entirely reasonable to expect this to >work. Altering gcc.c won't have that effect. There are two relevant points here: (i) ld has to be able to generate an executable file and (ii) ld has to be able to generate a (presumably not executable) file which can be used as input to another ld run. It's possible to link a few different .o files into one .o file, that can not be executed. Internal references are resolved in this ld run and the resulting file can be used as input file in another ld run (use the `-r' option). Therefore, ld actually doesn't need to produce an executable file. I respect your opinion, that ld should be able to generate a Minix executable file but, on a conceptual basis, I don't like ld producing output files with different kinds of headers (i.e. Minix header for an executable and GNU header for a relocatable object file). I think that it's best to preserve the GNU format as long as possible and to convert to Minix format as late as possible (i.e. in gcc.c). >Secondly, patching gcc.c is not easy. It's pretty awkward to keep track of >the existing link-spec code without making it even more difficult. That's only a matter of experience with reading source code. Some people find it very hard to read Prolog programs, while other people find Prolog the most natural programming language in the world! These discussions get really fast into religious kinds of argumentations and I don't want to start one here, but changing the variable link_spec is not difficult. The contents of link_spec is comparable to a shell script and is easy to change. >On the >other hand, gcc-ld consists of lines like > > do_something(); > do_something_else(); > >which make it extremely easy to add a three line patch > > #ifdef MINIX > do_convert(); > #endif > >The conversion routines themselves live in separate files which are totally >independent of gcc-ld, thereby "future-proofing" them against changes in >gcc-ld itself. Agree. >I must admit that I still have a leaning towards Alan Black's idea of getting >MINIX to understand GNU format a.out directly. His solution of the chmem >problem is pretty neat as well. However I do wonder what happens if MINIX >includes <a.out.h.gnu> - does it then get covered by the copyleft ??? I think, that a.out.gnu.h has NOT been defined by the FSF, but they have copied it from others. The GNU object header is compatible with Sun's object headers and I don't think that they pay Sun or AT&T for that, so I guess that you can use the GNU header without copyleft problems. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (02/05/91)
The task of the shell script you sent could certainly easily be included in gcc (I mean the compiler driver). C.v.W.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (02/05/91)
You are absolutely right, calling 'ld' by hand should produce a working binary from object files. This is the reason why I proposed that gcc-ld should exec() the conversion program. This should be transparent. C.v.W.