Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!samsung!uakari.primate.wisc.edu!caen!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: gcc question
Message-ID: <4fe48488.1bc5b@pisa.ifs.umich.edu>
Date: 18 Feb 91 19:41:00 GMT
References: <2323@tuvie.UUCP>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 26

In article <2323@tuvie.UUCP>, mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) writes:

  but while cc allocates the program image to the read-only text section,
  gas stores the stuff in in the r/w data section. Which - I think -
  means that the image is not shareable (except if Apollo uses 
  fancy copy-on-write strategies - does anybody know this ?). Also,
  this can lead to inadvertant program corruption:

This is one of the reasons why I don't use gcc much.

I thought this was documented in John Vasta's mods, but I can't find
anything about it now.  The problem is that gcc produces references to
library routines in the text segment, but these references have to be
resolved at load time, because of dynamic linking.  John's solution was to
have gas put all the text into the data section where the loader would be
able to adjust the references at run time.

A better solution might be to fix gcc to call every external routine through
an ECB, like Aegis used to do before sr10.  This would increase the call
overhead and would be hard to do unless you're familiar with the innards of
gcc.

An even better solution might be to only do this for symbols that appear in
the KGT at the time of compilation, like Domain/OS does.  This is even
harder, and makes me uncomfortable because the KGT on the target machine
won't necessarily match that on the development machine.