[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()

From: Mike Thomas
Subject: RE: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()
Date: Mon, 19 Apr 2004 12:22:12 +1000

Hi all.

On the weekend I wrote:

| PART 1: read_fasd()
| I happened on a combination of gcc optimisation flags which gave a
| repeatable hang on Windows in read_fasd1 (o/fasdump.c) while loading
| ansi-tests/rt.o.
| It turns out that the local variable "leng" in that function declared as
|   "int" receives an erroneous result from "getc()" via the GETD macro
| while reading the fasd data appended at the end of "rt.o":
|        case DP(d_short_string:)
|       fprintf ( stderr, "rf1 d_short_string, byte i = %x\n", i );
|       leng=GETD("leng=%d");
|       fprintf ( stderr, "rf1 leng = %d\n", leng );
|       leng = LENGTH(i,leng);
|       fprintf ( stderr, "rf1 Before READ_STRING, leng = %d\n", leng );
|       READ_STRING(leng,loc);
|       fprintf ( stderr, "rf1 After READ_STRING\n" );
|       return;
| The erroneous result is -122 which really should be 134 (134 + 122 =
| 256).  Redeclaring "leng" as "unsigned char" fixes that immediate
| problem but a crash occurs later anyway so presumably there are other
| places where such problems may be occurring.
| I suppose that this could be some interaction between the mixed
| optimisation settings and the "-fsigned-char" compiler flag and possibly
|   even the GCL custom linker.  Perhaps the C linker would normally do
| stuff to help optimise across module boundaries and seamlessly connect
| functions which have been optimised differently which our linker doesn't?

Having searched the MinGW32 mailing list, it turns out that this is a known
bug in MinGW32 runtime version 3.2 "getc()":


At this stage I don't know whether it applies to earlier versions of the
runtime but I would assume so.

Unfortunately 3.2 is the current version of the MinGW32 runtime.  I'll make
some enquiries.


Mike Thomas.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]