Pentium GCC patches/binaries for OS/2
------------------------------------------
Last updated on 30 Apr 1998, at 17:00
GMT-3EDT.
PGCC 1.0.2 is here! I've spent a day to update source tree to pgcc 1.0.2,
let's hope the efforth was worth it. To see what's new, refer to the section
Changes below.
Good news: I've found at last the time to fix some minor bugs in latest
release of pgcc-1.0. I've received a number of letters asking me how to work
around them, so I thought it will be much easier for me to say 'pull the
latest version' instead of going each time into technical details how and
what should be worked around.
What you can expect (relatively) soon:
Multithreaded Exceptions. There is already a patch which brings
multithreaded exceptions into egcs, but it is tested since February and will
be brought into main development trunk when 1.1.0 will come out. After this
I'll have to do a bit (or a lot :-) of work to make them work under OS/2.
Bug warning
There is a bug in optimizer of pgcc-1.0 AND pgcc-1.0.2 which can lead to
erroneous code generated. Sometimes a register is clobbered then tried to
use its previous value although it already contains some other value. This
is VERY rarely happening (I know only two affected programs:
zlib::infcodes.c (any version) and perl::miniperl.c (don't know which
version, but somewhere around 5.000).
I know of following workarounds:
* do NOT use -O5 or -O6 optimization switches (use -O4 and below)
* Use -fno-inline-functions
* Use -fno-force-mem
* Use -fno-ommit-frame-pointer
There are also a couple of other switches which cures the bug, but they
present only academical interest :-)
Marc Lehmann told me it was fixed in pgcc/egcs > 1.0.0, but I've checked it
and now see he was wrong :-(.
This is the only serious bug I know of as today. I'd say this is a VERY good
result, don't you think? :-)
A sidenote for programmers
You can visit the CrystalSpace homepage for a new free (GPLed)
6-degrees-of-freedom 3D engine. It is currently my main free-time project
(I've made the OS/2 port and working hard on many other aspects). I have not
seen any OS/2 programmers on CrystalSpace mailing list, so I think you're
just not informed :-) BUT! Please do not expect to find a ready-to-use
product, its still in developement stage. It is even not a library for now
(just a executable, not more). Please download CrystalSpace only if you want
to join the project, otherwise you will have to wait at least for next beta.
The patch below is dated 1.0.2. You will need also (at least) EMX runtime
installed and set-up properly (I presume you already did it if you're
reading this :-) since the compiler binaries requires EMX runtime DLLs, but
if you want to do anything serious with it, I recommend installing entire
EMX (esp. counting that its not so big).
------------------------------------------------------------------
I've ported GAS 2.8.1 to OS/2! It is not strictly needed if you just need a
high-level language compiler such as C or C++, but you should consider
downloading it if you:
* Use assembler inlines frequently - GAS 2.8.1 has a more strict syntax
check than bundled with EMX/GCC GAS 2.6 - for example "movl $5, %cl" is
a valid instruction for GAS 2.6 and is not a valid instruction for GAS
2.8.1.
* GAS 2.8.1 supports new P6 and P5 instructions including MMX. This is
the main reason why I've ported GAS 2.8.1.
I'm waiting for your comments and bug reports (related to the OS/2 port
only, of course).
Changes between several latest versions
pgcc-1.0.2 release 2 - minor bugfixes
* Re-compiled ld.exe and emxomfld.exe to not use gcc290.dll from
pgcc-1.0.0
* Changed front-end to pre-define __OS2__ symbol when using -Zomf
* Fixed an inconsistency between ld and emxomfld: ld used ldstub.bin when
run with -Zexe while emxomfld searched for nullstub.exe. Now the
"launcher" stub is always called ldstub.bin.
* minor bug in emxfix.cmd: lib/st and lib/mt already exists, so there is
no need to create them.
* New libraries: gpp*.a (which have almost the same functionality as
their gcc*.a counterparts). I was forced to split g++ runtime from gcc
runtime since g++ when used with frame-unwind exceptions required a
slightly longer initialization sequence which pulls a lot of unused
code into executables, even for plain C and F77 not speaking of C++
code without exceptions. So I suggest now linking with gcc even C++
code without exceptions - this will produce slightly smaller
executables (5-10K).
* Fixed the bug with creating a ".exe" file when feeding only linker
files to frontent (ex: gcc -s a.o b.o c.o will produce ".exe"). Now it
takes the basename of first object file and appends .exe or .dll.
pgcc-1.0.2 for OS/2
* Upgraded to egcs-1.0.2.
* Ooops! Due to a bug in my makefiles, libgcc previously used C versions
of some functions instead of optimized versions I wrote in
config/i386/emx-libgcc1.asm. 64-bit division should be slightly faster
now.
* Renamed dynamically-loaded libgcc from gcc290.dll to gcc29027.dll. This
happened because libgcc in pgcc-1.0.2 has been changed, to avoid
conflicts with previous versions of gcc*.dll.
* Added include/cpp/new, include/cpp/exception, include/cpp/typeinfo
files. I don't really know what they are for :-) I don't use libstdc++.
* Included GNU -liberty library into base PGCC/2 binary distribution. The
files added were:
o libiberty.h - mostly interface for string functions in libiberty
o objalloc.h - obstack management
o obstack.h - same
o getopt.h - GNU getopt (getopt_long included too). Replaces EMX's
getopt.h
o demangle.h - C++/Java name demangling functions
o fnmatch.h - Wildcard filename match function Replaces EMX's
fnmatch.h
o ansidecl.h - auxiliary file
o iberty.a - static library
o ibertydll.a - import library
o iberty.dll - dynamic library
To link against static version of GNU -liberty library use:
gcc [...] -liberty
To link against dynamic version of GNU -liberty library use:
gcc [...] -libertydll
iberty.dll should be on your LIBPATH (and distributed with your
programs, if used). It should be distributed under GNU Library Public
License (LGPL) which can be found in file COPYING.LIB.
2nd release of PGCC-1.0
* multi-threaded and single-threaded libstdc++ library! multi-threaded
libstdc++ uses emx's fast mutex semaphores (fmutex) for synchronising
access to streams, so it is now REALLY multithreaded :-) The files
stdcpp.a and stdcpp.lib have been moved into /emx/lib/st/ and
/emx/lib/mt/ directories.
* fixed a bug with _IO_flockfile and _IO_funlockfile in libstdc++
* fixed a number of minor bugs in supplied header files
o removed limits.h - emx's is good enough
o removed float.h - emx's is good enough
o removed sysinclude.h which is garbage
o removed proto.h which is garbage
o fixed a definition conflict with emx headers in varargs.h and
stdarg.h
* changed behaviour of command-line help. Now by default "gcc -h" will
list a digest of most used GCC options. To see the full help index use
gcc -h* or gcc --help=*
1st release of PGCC-1.0
* My Command-Line help patch is now included! Try gcc -h or gcc --help
and tell me what you think :-)
* libstdc++ (AKA stdcpp.a) is now included into gpp archive.
* IOstream and GNU Fortran manuals are included into the doc archive (in
INF format).
* Caught a bug! in old ld included with EMX. It does not importing
properly symbols from dynamically-linked libraries into the data
segment. I.e: { static FILE *f = stdio; } won't work with -Zcrtdll
since stdio is exported from C runtime DLLs, and f is placed into .data
section. Now it works properly (ugh).
* G++ exceptions now works (although I didn't have time to check it
deeply). I've had to add the support for exceptions into EMX libraries,
so you will need a separate lib/ directory for the new PGCC containing
the modified versions of EMX' libraries. The libraries themself are
partly contained in pgcc-os2-1.0.2-gcc.zip archive, partly made with
the emxfix.cmd file included in same archive. You should run it right
after unpacking the archive.
The dark side is that exceptions are for now single threaded. That is,
you must be sure that no two (no three, no four etc :-) exceptions will
be triggered at same time in two threads of your program, otherwise
most likely you will crash. The cause is that GCC uses for exception
handling some global variables. However, I hope next release of PGCC
will be multithreaded, there is already a patch for this, but it
requires some work.
* EGCS-1.0 has a optional new sheduler called `haifa'. The precompiled
binaries were made with --enable-haifa, so it is enabled now. This
should (could?) give some performance gain with optimization levels
below PGCC's (i.e -O1 through -O3). PGCC optimizes better, as always
:-)
Tips and tricks
By default PGCC for OS/2 uses frame-unwind-info exceptions. This mean that
with -fexceptions (which is on by default) gcc will partially generate debug
info which is used then for frame unwinding during exceptions. Due to this
fact files become larger (sometimes up to ~50%!) but this exception
mechanism has the advantage of having NO overhead on code execution time.
That is, try {...} catch () {...} generates NO code at all, so the programs
runs as fast as before. The disadvantage of this is executable size, of
course. Nothing comes from nothing. So, if you DO NOT use exceptions, you
SHOULD turn them off (by using -fno-exceptions switch) - this will greatly
reduce your code size.
There is also a alternative method for handling exceptions. It is called
setjump/longjump method, and as you understand it uses setjmp/longjmp
instructions. When try {} is encountered, a setjmp() is executed, and when a
exception is thrown it longjumps to the last setjmp(). This method generates
LOTS of messy code (most other PC C compilers uses same method - I've took a
look at Watcom and BCPP) which decreases execution time but occupies less
than frame-unwind-info. To use this exception handling method you should use
the -fsjlj-exceptions switch.
Please do not mix code compiled with sjlj-exceptions and with
frame-unwind-info exceptions! Exception won't cross the boundary between
different-style exception handling code, so most likely you will got a
'unhandled exception'. Actually this includes inability to use pre-compiled
libstdc++ with -fsjlj-exceptions (it was compiled with frame-unwind-info
exception handling).
I'm thinking hard about switching to sjlj-exceptions by default. I do not
know what advantage is better: speed or size. Plus because of the old a.out
format gcc for OS/2 uses the things are even worse with frame-unwind-info
(a.out do not support multiple sections other than .code and .data - if it
would, exception info could be grouped together in a separate piece and
loaded-on-demand -- but it can't :-( ). Please test frame-unwind-info
exceptions and tell me what do you think.
------------------------------------------------------------------
[Image]WARNING:
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Differences between PGCC and GCC/EMX 2.7.2.1
Here are the differences between PGCC-1.0 and GCC 2.7.2.2. This GCC port is
based on Eberhard Mattes's GCC/EMX patches (note that I took his name into
... brackets... guess why ;-), but were (already) heavily modified,
so not everything should work as in GCC/EMX 2.7.2.1. There are some small
differences which I will list below:
1. The -ZC++-comments switch is gone now (hopefully forever) since the
preprocessor (CPP) always enable C++-style comments (unless
-traditional or -lang-c89 is specified -- and of course unless language
itself does not use C preprocessor (CPP)).
2. All compilers were compiled with -Zcrtdll, so you will need an
installed EMX runtime to run them. Can't imagine why you need GCC if
you don't have EMX :-)
3. The -Zexe switch now works correctly (before it worked only in couple
with -o switch). ld and emxomfld were patched too for this (although it
is not required). They are as well a part of pgcc-os2-1.0.2-gcc.zip
archive.
4. The -mprobe switch is retained for backward compatibility, however it
is highly recommended that you use -mstack-arg-probe and
-mno-stack-arg-probe instead since these options are new from
mainstream GCC version, and maybe someday -mprobe will disappear.
5. Now alloca() is stack-probe safe, i.e. if you`re compiling with
-mstack-arg-probe switch, alloca() will do stack probes for you.
However, the previous limitation still applies, i.e. if you will do
alloca(4095) twice, this can lead to a crash. The best workaround for
this is to not use threads with non-commited stack at all :-)
6. The provided binaries of GCC will not work in DOS (with EMX or RSX
extenders) since
> They were packed with LXLITE (no OS/2 2.x too)
If you need either to run GCC in DOS (note that you still can produce
executables that run in DOS), you can try to recompile it yourself. If
you want to run it under OS/2 2.x you should unpack executables (lxLite
-x -r *). If you can't do the listed above yourself, mail me - possibly
if I'll receive enough requests, I'll do a unpacked version.
7. The bounds-checking is not implemented at all... and I don't know if
ever someday it will.
8. The new C runtime DLLs are completely compatible with old ones (at
least they should be :-), but includes new entries for new functions in
libgcc.
9. (the worst) libg++ is not compatible at all with new G++... seems that
new G++ considers as errors many things that previous version didn't.
There is a new libgcc in egcs-1.0, I'll try to get it running ASAP.
10. 64-bit ([unsigned] long long) division is now FAST! :-) Its written in
assembly now, and I`ve optimized it by hand. It looks almost ~ten times
faster as before. Signed division is somewhat slower than unsigned, so
if you need speed, use unsigned when possible.
I should say that same routine, coded in plain C (take a look into
libgcc2.c) and compiled with PGCC -O6 is only 10-20% slower (!!!). This
makes me think this routine was the last in my life which I've
assembled manually ;-)
11. -mepilogue did not worked in C++ and possibly other languages which
mangles names. Now fixed.
12. _set_new_handler has been renamed into set_new_handler (ANSI C++,
imho). However, _set_new_handler will work too as an alias.
If you remember, some old versions of pgcc had the 'char' variable by
default unsigned. I've discontinued this since
1. This was in contradiction with older versions of gcc/emx
2. I've realized that not all DOS/OS2 C compilers have the char by default
unsigned, how I've thought at beginning.
3. Many parts of GCC when compiling emits warnings about such things as
'comparison is always X due to argument range limit' etc when char is
unsigned. This is not too important, but is somewhat discouraging.
4. This is a logical continuation of the line 'long
long/long/int/short/char'.
------------------------------------------------------------------
Known bugs and limitations
1. Currently ld crashes on big files (or many .o files). This is a
temporary problem since it is easily resolved: I've forgot to set up a
bigger stack size, so you can fix this problem by running
emxstack -s 512 ld.exe
I thought a new beta is not worth of such a small fix :-)
2. emxomf now traps (sometimes?) when compiling with -g (debug) switch.
This is due to new format of debugging info (DWARF2). I do not know how
to fix this. Use A.OUT format (no -Zomf) for debugging and pmgdb.
3. f77 compiler does not incorporate the changes made for the `main'
ported version for OS/2. I do not know whenever there are other changes
other than those needed `just to make it work', I should investigate
this as soon as possible.
------------------------------------------------------------------
Build instructions
If you want to build PGCC/OS2 from scratch (if you're mad enough :-) here
are the instructions how to do it. Note that you either should be current
with Unix-style utilites (I mean the contents of
ftp.leo.org/pub/comp/os/os2/leo/unix/..., for example) or you should have
enough time to learn them (its easy, believe me... despite what m$
propaganda says ;-)
However, if I've succeeded to scare you (;-) you can just download the
binaries (skip this entire paragraph to next separator line) and enjoy.
[Image] To configure PGCC sourcecode to compile for OS/2 you should have:
* GNU Bash (proud to present... my own port ;-)
* GNU Make (I didn`t tested with DMAKE... don't like it)
* GNU file utils (ls, rm, mv etc)
* GNU text utils (cat)
* GNU sed
* GNU grep (maybe others will work too...)
* GNU bison
* GNU C/EMX 2.7.2.1 (didn`t tested with earlier versions)
* GNU perf (not required)
* GNU flex (AFAIR not required)
* Don't forget to put sh into /bin subdirectory... although theoretically
EGCS' Configure supports ${CONFIG_SHELL} variable, it often ignores it
and runs /bin/sh directly... shame on cygnus :-)
* hmmm... maybe I forgot something ;-) As soon as you'll get a 'command
not found' message, ftp to ftp.leo.org and grab the appropiate tool.
Every Unix tool I use I've downloaded from there.
When you have everything listed above, you should:
1. Get the entire EGCS-1.0 distribution archive and unpack it to some
directory $(EGCS)
2. Get all the EGCS patches and apply them.
3. Copy the contents of the diff/egcs/ subdirectory into the $(EGCS)
subdirectory (recursively with all subdirectories).
The slow (but complete) way :-)
1. Launch $(EGCS)/Configure with bash. This takes lots of time (up to
some minutes!) since it have to recursively walk through all
subdirs and launch Configure there too.
2. Now launch "make" in $(EGCS) directory. You should be prepared to
wait for a LONG time :-)
3. First will be made GNU -liberty library and some other things,
then it will launch the make process for GCC. Here at some point
it can fail. If it does so, proceed as below.
The quick way (if you need only
gcc/gpp/objc/f77/libgcc/libf2c/libobjc)
1. Launch $(EGCS)/gcc/Configure with bash (with optional
--enable-haifa command-line parameter). This won't take so long as
the root Configure, and besides you at least have what to look at
during the process :-)
2. Launch "make" in same directory.
If make tries to run 'autoconf' (which you most likely don't have), run
'touch configure', then re-run make. If make tries to launch 'autoheader'
(which is a part of autoconf package too), touch cstamp-h.in then re-run
make. These problems can show up because of inconsistency between time/date
stamp of these files after applying patches.
When GCC compilation will be done, you should build a stage2 compiler.
Stage1 compiler contains debug info so it is usable only for debugging
purposes. A stage2 compiler is built using stage1 compiler (i.e. the
compiler you already have -- with debugging info)
To build stage2 compiler using stage1 compiler (also a stage(n+1) compiler
using stage(n) compiler) you should launch:
bash emx-nextstage
in the $(EGCS)/gcc/ directory.
You can run emx-nextstage up to three times to make stage2 through stage4
compilers. Each successful stage tells you have a compiler that at least can
build itself from scratch.
If you still have problems you should read the file $(EGCS)/INSTALL - it
contains some general instructions on building egcs. Keep in mind that they
are for Unix, not for OS/2.
When you're done playing with stageN compilers, you should take the compiler
from the $(EGCS)/gcc/stageN/ subdirectory (where N is the latest stage you
built) and copy it where you want it. The usual for Unix 'install' process
is not supported, I don't see why I should do it. OS/2's directory structure
is not hardcoded as Unix's, besides each user have its own preferences where
to keep the compiler and the libraries. I'll only list the files that are
part of the final product:
cc1.exe
The C compiler
cc1plus.exe
The C++ compiler
cc1obj.exe
The ObjectiveC compiler
f771.exe
The Fortran77 compiler
cpp.exe
This is the C Preprocessor
xgcc.exe
The GCC driver. Rename it to gcc.exe
g++.exe
The G++ compilation driver. See the comment about g77.exe
g77.exe
The Fortran77 compilation driver. Same as gcc.exe, the difference is
that you can get a gcc.exe without f77 support (if the f/ subdirectory
was missing during configure process), but you'll never get a g77
without that. Besides this, this driver will add the required -lXXX
switches for given language (-lstdc++ for C++, -lf2c for Fortran).
gcov.exe
This is a 'coverage test program'. What it really means I don't know
since I didn't have time to figure it out. I think it should do
something, it's even documented in the GCC documentation :-)
c++filt.exe
This program will take a g++-mangled name and display how it looked
before mangling. Usually gcc/ld/etc will display themself demangled
names, so you won't need them. However, if you will have to dig through
a C++-generated .S file, you'll need it, I bet. Example usage:
c++filt.exe __6classAipcc
will display
classA::classA(int, char *, char)
More complex usage example:
[1|home|d:/emx/_tmp_]nm z.o
0000000c T __$_1A
00000000 T ___1AiPc
U ___builtin_delete
00000000 t ___gnu_compiled_cplusplus
U ___main
00000030 T _main
00000000 t gcc2_compiled.
[1|home|d:/emx/_tmp_]nm z.o|c++filt.exe
0000000c T A::~A(void)
00000000 T A::A(int, char *)
U ___builtin_delete
00000000 t ___gnu_compiled_cplusplus
U ___main
00000030 T _main
00000000 t gcc2_compiled.
gcc.a, gcc_p.a, gcc29027.a and gcc29027.dll
This is the GCC runtime library. The makefile will build two versions
of libgcc: one for profiling (gcc_p.a) and the usual gcc runtime
(gcc.a). Besides this, make will build a dynamically-linked version of
libgcc called gcc29027.dll and the import library gcc29027.a. I've
decided to split libgcc from EMX runtime DLLs since they changes with
each version of gcc, and this makes EMX DLLs a mess.
objc.a
This is the ObjectiveC runtime. I don't know really what I should do
with it, so I've just included it into the ObjectiveC distribution :-)
f2c.a
This is the Fortran77 runtime library.
include/*/*
The gcc/include subdirectory will contain a version of system-dependent
include files built right for the version of GCC you just made. You
should grab almost everything you'll find there, except that you'll
need to put 'new.h', 'new', 'exception' and 'typeinfo' files into the
cpp/ subdirectory. You also should delete the 'fixed' and 'README'
files as they are of no use.
------------------------------------------------------------------
Whom to contact in case of problems
* If you have problems with the installation or configuration, please try
to solve them yourself. If you want to recompile GCC you should be
skilled with EMX and have basical knowledge of Unix tools.
* If you have problems with the generated code, i.e. the compiler does
produce wrong output, consider asking your question on the beastium
mailing list. Refer to the FAQ on how to subscribe.
* If you have problems regarding the OS/2 port itself, you can contact me
by e-mail [Image]
------------------------------------------------------------------
The patches
* The patches are included in the main archive pgcc-os2-1.0.2-gcc.zip in
the diff/ subdirectory. This directory also contains a number of
patches (some needed, some not) to the emx runtime, to some emx tools
(ld and emxomfld) and to GNU make. Most notable patch to ld is its
ability to handle both 'something.a' and 'libsomething.a' library
naming scheme. This comes in very handy when using Unix makefiles
without modifications.
Also it was modified to allow exporting not only code-segment entries,
but data and bss segment entries too. I'm not sure, but I think you
will need this new ld to build libgcc.
------------------------------------------------------------------
The binaries
Filename Size Description
GNU compiler front-door
(GCC), C PreProcessor
pgcc-os2-1.0.2-gcc.zip 1153108 bytes (CPP), GNU C compiler
(CC1), ld, emxomfld,
libraries and some short
docs
pgcc-os2-1.0.2-gpp.zip 1494404 bytes GNU C++ compiler (needs
previous archive).
GNU Objective C compiler
pgcc-os2-1.0.2-goc.zip 837548 bytes plus Objective C runtime
library & headers
GCC documentation
pgcc-os2-1.0.2-docs.zip 780570 bytes converted from .texi
into OS/2 .INF book
format
os2_pf77_r currently os2_p77_r_size
unavailable currently GNU Fortran77 compiler.
unavailable
gas-2.8.1.0.1-bin.zip GNU assembler version
2.8.1 with docs.
GNU assembler version
gas-2.8.1.0.1-diff.zip 2.8.1 differences from
released sources.
------------------------------------------------------------------
This page is maintained by Andrew Zabolotny,