Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!vasta
From: vasta@apollo.HP.COM (John Vasta)
Newsgroups: comp.sys.apollo
Subject: Re: gcc question
Message-ID: <4fea5346.20b6d@apollo.HP.COM>
Date: 19 Feb 91 22:56:00 GMT
References: <2323@tuvie.UUCP> <4fe48488.1bc5b@pisa.ifs.umich.edu>
Sender: root@apollo.HP.COM
Reply-To: vasta@apollo.HP.COM (John Vasta)
Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA
Lines: 40

In article <4fe48488.1bc5b@pisa.ifs.umich.edu> rees@citi.umich.edu (Jim Rees) writes:
>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.

Yep, that's my hack. I mention it in my APOLLO-GCC-README file:

  3. The compiler generates code which is link-compatible with the
     Apollo C compiler and libraries. The GNU assembler was hacked to
     produce COFF output modules. In order to use the Apollo global
     libraries, the code sections are actually put into writable data
     sections, so that the loader can relocate them (GCC doesn't
     generate code which needs no relocation, like the Apollo
     compilers). This means that program text cannot be shared, and
     loading may take slightly longer, but I don't think it will be
     noticeable.

Sorry, but I didn't have time to implement significant changes in GCC
code generation. I also didn't expect folks would try to use GCC for
real production work; I thought it would come in handy for quick porting
of code which depended on GCC quirks or full ANSI behavior. And now
that Apollo's C compiler is full ANSI, there's one less reason to use GCC.

John Vasta                Hewlett-Packard Apollo Systems Division
vasta@apollo.hp.com       M.S. CHR-03-DW
(508) 256-6600 x5978      300 Apollo Drive, Chelmsford, MA 01824
UUCP: {decwrl!decvax, mit-eddie, attunix}!apollo!vasta