🚀 go-pugleaf

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