mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (02/17/91)
We just compiled sicstus Prolog for the Apollo with both /bin/cc and
gcc. While gcc offers some things which are A Good Thing for compiling
Prolog interpreters (like allocating global variables to registers),
the size command exposed a problem:
% size //hal/usr/local/lib/sicstus0.7*/E*/sp*
gcc: text(r) data(r/w) bss(r/w)
//hal/usr/local/lib/sicstus0.7-P3/Emulator/sp: 292 + 127736 + 1104 = 129882
cc: text(r) data(r/w) bss(r/w)
//hal/usr/local/lib/sicstus0.7/Emulator/sp: 168752 + 8616 + 1080 = 251862
Sizes per se (the sum of all sizes) are absolutely uninteresting,
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:
main()
{
*((long *)main) - 0;
}
executes without protection violation - yuck !!
Has anybody found a workaround for this problem? Any hints will be
appreciated.
bye,
mike
Michael K. Gschwind, Institute for VLSI-Design, Vienna University of Technology
mike@vlsivie.tuwien.ac.at 1-2-3-4 kick the lawsuits out the door
mike@vlsivie.uucp 5-6-7-8 innovate don't litigate
e182202@awituw01.bitnet 9-A-B-C interfaces should be free
Voice: (++43).1.58801 8144 D-E-F-O look and feel has got to go!
Fax: (++43).1.569697 rees@pisa.ifs.umich.edu (Jim Rees) (02/19/91)
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.vasta@apollo.HP.COM (John Vasta) (02/20/91)
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