Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: Unified MINIX GNU port
Message-ID: <744@philica.ica.philips.nl>
Date: 4 Feb 91 14:51:13 GMT
References: <43079@nigel.ee.udel.edu> <739@philica.ica.philips.nl> <1985@Terra.cc.brunel.ac.uk>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 70

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