jand@kuling.UUCP (Jan Dj{rv) (07/04/90)
I submitted an article sometime ago about gcc on HP-UX 7.0. I received many useful hints. Those who replied where Paul Anderson <paul@lfcs.edinburgh.ac.uk> Dave Von Bank <dvg@hpldola.hp.com> Bob Desinger <bd@sde.HP.COM> Glen R. Engel <glenne@hplsla.hp.com> Kaleb Keithley <kaleb@thyme.jpl.nasa.gov> Tom Lane <Tom.Lane@ZOG.CS.CM> Paul Raveling <Raveling@isi.edu> Thanks everyone. Tom Lane supplied me with diffs that made it possible to make gcc (included in a separate posting). There are many problems in making gcc. HP-UX malloc (in libc.a) and alloca (in libPW.a) seems to be broken. Fortunately there's an alloca distributed with gcc (1.37.1). Kaleb, Glen and Tom pointed this out to me. Kaleb writes: Uncomment ALLOCA=alloca.o in the Makefile. gcc-1.37.1 comes with alloca.c; this will force alloca.c to be compiled. I haven't tried this on HPUX, but Sun's alloca is broken, and requires the same fix. The INSTALL file appears to be outdated; it still says 1.36, and the reference to alloca seems to predate even 1.36, as 1.36 came with alloca.c. Bob writes this about alloca and HP: A year or so I looked at the -lPW alloca source on HP-UX for the Series 800; it was identical to the GNU alloca. They were both based on Doug Gwyn's (or was it Ron Natalie's?) public-domain code. But I guess either the Series 300 version is different, or else GNU and HP-UX sources diverged. GNU:s alloca is based on Doug Gwyn's alloca. If you are making g++ amd libg++ you must use GNU:s malloc or -lmalloc when compiling. I found that g++ produces incorrect code for functions declared inline if standard malloc is used. Many tests for libg++ will fail if standard malloc is used. I've found that the malloc that comes with g++ and gdb works best. Use it when compiling gcc, g++ and libg++. Do not use the malloc that comes with libg++. It also makes some tests fail. I think HP shuld merge -lmalloc into libc. Having two malloc:s is only confusing. A final word on alloca from Tom: NOTE: gcc -O is VERY VERY slow with the portable alloca. I find it fastest to build stage2 without -O, then to make a production third stage with -O turned on. HP:s setvbuf appears to be broken. This affects gas. When setting linebuffering on a file, the first character of that file is lost. No rewinding or seeks can undo that fact. Gas inserts a '#NO_APP' comment (# indicates comment) but the # is lost and gas breaks. There is a warning about this in the Makefile of gas-1.36. GNU:s ld has problems. If it finds that a .o file of an archive is needed it loads all symbols from that .o file, regardless if some of those symbols have been defined previously. This affects programs which defines there own exit. A workaround for this condition is to rearrange some symbols of libc.a (included in the patches). However, this does not solve all the problems, Tom writes: HP's ld seems to be able to deal with libraries containing symbols that are also defined elsewhere, whereas gnu-ld just barfs. I wanted to build emacs with X support, and HP's X11R3 libraries contain some subroutines that have the same names as stuff in emacs. This can become a major problem. Seems that GNU must make a better ld. However, using HP:s ld & as can also cause trouble, Bob writes: I compiled gcc and got it to work occasionally under 7.0, but it intermittently dies when compiling. It gripes about unexpected EOF on some assembler source file in /tmp/. If I re-run the same job (by typing "make" again, usually), it usually succeeds. I'm not sure, but I think that gcc tries to be fast by invoking the assembler before it's finished writing the assembler source file. If this is true, then the HP-UX assembler must be too fast for gcc. I didn't spend a lot of time on it, though, and abandoned it soon after. (I needed an ANSI compiler to test something out. Once the test was over, I didn't need the compiler.) I haven't tested this, but the info can be useful to those using HP stuff. Some minor details: The subdirectory binutils/hp-include/sys must be removed on HP-UX 7.0. The symbols _etext, _edata and _end requires an extra underscore (i.e. __etext, __edata, __end) under HP-UX. If you get a 'Undefined symbol' warning about these, just prepend a _. The stdio.h in libg++ want's 'char' in the iobuf struct. HP:s has 'unsigned char'. This could be a source for trouble, but I haven't noticed any yet. Changing to 'unsigned char' will cause LOTS of errors when compiling libg++. It requires lots of changes to overcome this. Thus, I haven't done it. Compiling libg++ itself produces heaps of warnings. Just ignore these. All these info has been posted to the GNU people. Hopefully it will be easier to build gcc and g++ in future releases. Jan D.
piet@cs.ruu.nl (Piet van Oostrum) (07/05/90)
The alloca() from libPW does indeed give performance problems, as does the portable one supplied by GNU. There is an assembler alloca in gnu emacs, but that one is broken. It can lead to stack corruption during a signal handler. I have a patch for that, and I also have rewritten it from scratch. Here follows a free one: # This assembly routine implements alloca (n) # The HP compiler does "move.m <registers> (%sp)" to save registers, # so we must copy the possibly saved registers to the top of stack. # The stack layout at entry is: # possibly saved regs # n # return address <--- sp set MAXREG,22 # d2-d7, a2-a5, fp2-fp7 may have been saved text global _alloca _alloca: move.l (%sp)+,%a0 # save return addess move.l %sp,%d0 # old stack pointer sub.l (%sp)+,%d0 # subtract number of bytes requested or.l &3,%d0 # prepare for longword alignment # now d0 = return value - 1! sub.l &MAXREG*4-1,%d0 # allocate space for saving registers move.l %sp,%a1 # source for reg copy move.l %a2,%d1 # save reg a2 move.l %d0,%a2 # dest for reg copy move.l %d0,%sp # save new value of sp move.w &MAXREG-1,%d0 # loop counter copy: # save possibly saved registers move.l (%a1)+,(%a2)+ dbra %d0,copy move.l %a2,%d0 # return value move.l %d1,%a2 # restore reg a2 add.l &-4,%sp # this compensates for add.l &4,%sp # generated by the compiler jmp (%a0) # rts -- Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31-30-531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31-30-513791 Internet: piet@cs.ruu.nl (*`Pete')
brown@hpdmd48.HP.COM (Kevin Brown) (07/12/90)
Compiling the binutils on a hp9k300 I get: >> cc -g -Ihp-include -DUSG -DNON_NATIVE -o nm nm.o \ >> getopt.o getopt1.o cplus-dem.o alloca.o gmalloc.o >> ld: Undefined external - >> _getpagesize >> ld: output file still contains undefined symbols >> ld: (Warning) did not generate an output file >> *** Error code 1 What is getpagesize? Kevin Brown Boise Printer Division brown@hpbsm15.boi.hp.com
milburn@me10.lbl.gov (John Milburn) (07/13/90)
>Compiling the binutils on a hp9k300 I get: > > >> cc -g -Ihp-include -DUSG -DNON_NATIVE -o nm nm.o \ >> getopt.o getopt1.o cplus-dem.o alloca.o gmalloc.o >> ld: Undefined external - >> _getpagesize >> ld: output file still contains undefined symbols >> ld: (Warning) did not generate an output file >> *** Error code 1 getpagesize is defined in ld.c, which is part of the gnu binutils package: getpagesize () { return (4096); } I don't know why you would get this error when trying to link nm with the hp link editor, but perhaps you are having some trouble with gnu ld. -jem -- JEMilburn@lbl.gov ...!ucbvax!lbl.gov!JEMilburn
brown@hpdmd48boi.hp.com (Kevin Brown) (07/13/90)
>> cc -g -Ihp-include -DUSG -DNON_NATIVE -o nm nm.o \ >> getopt.o getopt1.o cplus-dem.o alloca.o gmalloc.o >> ld: Undefined external - >> _getpagesize >> ld: output file still contains undefined symbols >> ld: (Warning) did not generate an output file >> *** Error code 1 > getpagesize is defined in ld.c, which is part of the gnu binutils package: > >getpagesize () >{ > return (4096); >} I have looked into it further: it is gmalloc that calls getpagesize but never defines it. It is true that the 'ld' code defines it for itself. I am further confused 'cuz the source for gmalloc has ominous warnings about editing the file 'cuz it was automatically generated. I've also had trouble compiling ranlib 'cuz it can't find xmalloc. It looks like the alloca.o that I got out of the gcc directory wants to call xmalloc. This wasn't a problem for: ar,gprof,ld, nm objdump, size, and strip 'cuz they all define their own xmalloc. Any one got any hints? Did I leave something important out or not set a flag properly? Thanks Kevin Brown brown@hpbsm15.boi.hp.com