Subject: Re: 14-Sep Toolchain Update /m68k /libgnumalloc
To: Erik Bertelsen <firstname.lastname@example.org>
From: Erik Bertelsen <email@example.com>
Date: 10/12/1998 23:17:40
On Thu, Sep 17, 1998 at 09:45:19PM +0200, Erik Bertelsen wrote:
> However, I have observed another problem that I never got around to report:
> On my mac68k, several problems (diff and cpp) went into a cpu-bound loop if
> a egcs 1.1-built libgnumalloc.so was active, but reinstalling a previous
> version got them working again.
I have now done some more work to isolate this problem:
If libgnumalloc.so is compiled with EGCS 1.1 with CFLAGS=-O, several programs
will loop indefinitely, e.g. cpp, cc1, diff. Reinstalling the pre-egcs-1.1
libgnumalloc.so (just the binary) makes the problem go away.
Today I verified that installing libgnumalloc with egcs 1.1, but without
optimization produces a working version. I also found out that compiling
all files except combined.c with -O results in a usable library.
I've found out that diff /usr/sys/syscallargs.h /usr/src/sys/sys/syscallargs.h
loops, even if the files are equal when using the bad libgnumalloc.so.
Diffing some other files (both smaller and bigger) does not cause diff
to loop. However, all compiles seem to loop in either cc1 or cpp.
Finally I built libgnumalloc with -g -O and diff with -g, and apparently
it loops in malloc.c in the loop from line 254 to line 280.
According to gdb, malloc has been called to allocate a block of size 4096,
the local variable block stays at the value 9 through each round of the loop,
while start is 18, which makes the loop continue.
I have not looked at the generated code to try to identify the bad code.
Except for this problem and the alignment warnings from sd.c (kernel)
and ifconfig.c I'm running a system (kernel and userland) built with