Waldek Hebisch wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
BTW: if the same happens with standalone program (without modules) I should be able to reproduce it.
Sorry, not clear to me what you mean.
I have build a cross-compiler targetting Mac OSX. However, I do not have the complete toolchain (only bare compiler). Without full toolchain I can not compile RTS (the problem really is configure) and also I can not compile anything using GPC module.
If you have a testcase which does not use GPC module (directy or indirectly) I should be able to compile it. In fact, if a program uses no extra modules (units) at all debugging becomes easier.
I have tried the cross-compiler on various test programs and ATM it happily produced stabs debug info.
OK, I understand, I will look for a testcase (or try to isolate the problem).
Some observations:
1. the problem does not occur when running gpc directly rather than with make, even when passing the same compiler switches (this sounds like random behaviour and makes me think there is an uninitialized variable somewhere in the compiler source code)
2. the problems disappears when I remove Turbo3 from the USES clause in aturbo3test.pas
3. the problem persists when I reduce the Turbo3 unit to nothing but
import
System (MemAvail => System_MemAvail, MaxAvail => System_MaxAvail);
Will try to further narrow this down in units/System.pas.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Some observations:
- the problem does not occur when running gpc directly rather than
with make, even when passing the same compiler switches (this sounds like random behaviour and makes me think there is an uninitialized variable somewhere in the compiler source code)
BTW, did you notice that aturbo3test.pas is tested via units.cmp which adds some options (in particular -DHAVE_CRT that triggers use of Turbo3)?
If you haven't done yet, you might add an echo in units.cmp to find out with which options GPC is finally called. It's the line:
$1 $2 $HAVE_UNITS
(Or just add -DHAVE_CRT manually.)
Another potential difference (though rather unlikely) would be environment variables.
Unintialized compiler variables seem not so likely for this kind of problem, as Unix-like systems usually zero program's address space before the start anyway.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Some observations:
- the problem does not occur when running gpc directly rather than
with make, even when passing the same compiler switches (this sounds like random behaviour and makes me think there is an uninitialized variable somewhere in the compiler source code)
BTW, did you notice that aturbo3test.pas is tested via units.cmp which adds some options (in particular -DHAVE_CRT that triggers use of Turbo3)?
If you haven't done yet, you might add an echo in units.cmp to find out with which options GPC is finally called. It's the line:
$1 $2 $HAVE_UNITS
(Or just add -DHAVE_CRT manually.)
OK, that explains it, the behaviour is not random.
Another potential difference (though rather unlikely) would be environment variables.
Unintialized compiler variables seem not so likely for this kind of problem, as Unix-like systems usually zero program's address space before the start anyway.
Anyway, fjf584a.pas and fjf584b.pas reproduce the problem in the testsuite (like PMemList does in units/system.pas).
Regards,
Adriaan van Os
Adriaan van Os wrote:
Anyway, fjf584a.pas and fjf584b.pas reproduce the problem in the testsuite (like PMemList does in units/system.pas).
I can now reproduce the problem, the following should fix it:
--- gcc-4.0.2/gcc/dbxout.c~ 2006-03-21 01:50:59.000000000 +0100 +++ gcc-4.0.2/gcc/dbxout.c 2006-03-30 02:07:55.483660880 +0200 @@ -2455,7 +2455,7 @@ we see following the TREE_TYPE chain. */
t = type; - while (POINTER_TYPE_P (t)) + while (POINTER_TYPE_P (t) && !TYPE_NAME (t)) t = TREE_TYPE (t);
/* RECORD_TYPE, UNION_TYPE, QUAL_UNION_TYPE, and ENUMERAL_TYPE
Waldek Hebisch wrote:
Adriaan van Os wrote:
Anyway, fjf584a.pas and fjf584b.pas reproduce the problem in the testsuite (like PMemList does in units/system.pas).
I can now reproduce the problem, the following should fix it:
--- gcc-4.0.2/gcc/dbxout.c~ 2006-03-21 01:50:59.000000000 +0100 +++ gcc-4.0.2/gcc/dbxout.c 2006-03-30 02:07:55.483660880 +0200 @@ -2455,7 +2455,7 @@ we see following the TREE_TYPE chain. */
t = type;
while (POINTER_TYPE_P (t))
while (POINTER_TYPE_P (t) && !TYPE_NAME (t)) t = TREE_TYPE (t); /* RECORD_TYPE, UNION_TYPE, QUAL_UNION_TYPE, and ENUMERAL_TYPE
Yes, it fixes the problem, thanks.
Regards,
Adriaan van Os
Frank Heckenbach wrote:
Adriaan van Os wrote:
Some observations:
- the problem does not occur when running gpc directly rather than
with make, even when passing the same compiler switches (this sounds like random behaviour and makes me think there is an uninitialized variable somewhere in the compiler source code)
BTW, did you notice that aturbo3test.pas is tested via units.cmp which adds some options (in particular -DHAVE_CRT that triggers use of Turbo3)?
If you haven't done yet, you might add an echo in units.cmp to find out with which options GPC is finally called. It's the line:
$1 $2 $HAVE_UNITS
(Or just add -DHAVE_CRT manually.)
OK, that explains it, the behaviour is not random.
Another potential difference (though rather unlikely) would be environment variables.
Unintialized compiler variables seem not so likely for this kind of problem, as Unix-like systems usually zero program's address space before the start anyway.
Anyway, fjf584a.pas and fjf584b.pas reproduce the problem in the testsuite (like PMemList does in units/system.pas).
Regards,
Adriaan van Os
-
Adriaan van Os -
Frank Heckenbach -
Waldek Hebisch