grunwald@flute.cs.uiuc.edu (05/12/89)
Configuration: sun3-os4, sun3/60, sunos-4 installed g++.xtar.Z of may 11th out of the can with virgin (except RFG patch to cccp.c) gcc-1.35, using 1.35 to compile. recompiled and installed current libg++. symptoms: when I try to run most programs, I get a seg fault with the following trace: free: illegal address (0x4c33a) (gdb) where #0 0x1ec08 in kill () #1 0x19906 in abort () #2 0x17620 in malloc_verify () #3 0x16ae0 in free () #4 0x1707c in realloc () #5 0x169d0 in malloc () #6 0x1a25c in on_exit () the on_exit is in crt0+.o -- it's line 457, ON_EXIT (_cleanup, 0); what this seems to indicate is that something w.r.t. malloc is getting mucked with. In this example, I was using the debugging malloc library on the sun-3. In other cases (libg++/tests/tFile), it justs dies in malloc(), presumably for the same reasons. libg++/tests/test0 *did* work, but it didn't get back the part where it tells you that you have a bogus crt1+.o Has anyone gotten this version to compile & run on a sun3? Any clues? -- Dirk Grunwald Univ. of Illinois grunwald@flute.cs.uiuc.edu
kevin%kalli@Sun.COM (Kevin Sheehan {Consulting Poster Child}) (05/14/89)
In article <GRUNWALD.89May11220605@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes: This is the infamous "unaligned" problem. What happens is that normal Sun linker ensure that everything is 4-aligned, g++-ld doesn't. Sooo, the startup code calls on_exit(), who calls malloc(), which calls morecore(), who hands back a 2-aligned chunk, on which free() barfs. (BTW, this was the first time I got to use gdb - kinda fun!) You have three options - fix morecore(), fix g++-ld, or add a bogus short someplace to cause your data/bss to be aligned... l & h, kev > >Configuration: sun3-os4, sun3/60, sunos-4 > >installed g++.xtar.Z of may 11th out of the can with virgin (except RFG patch >to cccp.c) gcc-1.35, using 1.35 to compile. > >recompiled and installed current libg++. > >symptoms: > when I try to run most programs, I get a seg fault with the following >trace: > >free: illegal address (0x4c33a) >(gdb) where >#0 0x1ec08 in kill () >#1 0x19906 in abort () >#2 0x17620 in malloc_verify () >#3 0x16ae0 in free () >#4 0x1707c in realloc () >#5 0x169d0 in malloc () >#6 0x1a25c in on_exit () > >the on_exit is in crt0+.o -- it's line 457, > ON_EXIT (_cleanup, 0); > >what this seems to indicate is that something w.r.t. malloc is getting >mucked with. In this example, I was using the debugging malloc library >on the sun-3. > >In other cases (libg++/tests/tFile), it justs dies in malloc(), presumably >for the same reasons. > >libg++/tests/test0 *did* work, but it didn't get back the part where it >tells you that you have a bogus crt1+.o > >Has anyone gotten this version to compile & run on a sun3? Any clues? >-- >Dirk Grunwald >Univ. of Illinois >grunwald@flute.cs.uiuc.edu
tiemann@YAHI.STANFORD.EDU (Michael Tiemann) (05/14/89)
The next release of the compiler includes a version of GNU LD which fixes this problem. Michael
Gordon@ucl-cs.UUCP (05/15/89)
> The next release of the compiler includes a version of GNU LD which > fixes this problem. > Michael Is a LD or NEWLD feature or both? And what is the diff betwixt and between these two? Gordon.
tiemann@YAHI.STANFORD.EDU (Michael Tiemann) (05/17/89)
Date: 15 May 89 14:37:49 GMT From: mcvax!ukc!strath-cs!nott-cs!ucl-cs!Gordon@uunet.uu.net Sender: bug-g++-request@prep.ai.mit.edu > The next release of the compiler includes a version of GNU LD which > fixes this problem. > Michael Is a LD or NEWLD feature or both? And what is the diff betwixt and between these two? Gordon. Fixed in both by forcing alignment of the text segment. LD is old and should not be needed anymore. NEWLD has the feature of reporting filename and linenumber of undefined external references. It also has other facilities which are undermined by most current UNIX assemblers. Changed which I put into LD have been merged into NEWLD, so both work equally well under GNU C++. Michael