Hello,
running gpc testsuite (gpc version 20041218, based on gcc-3.2.3) on x86_64-unknown-linux-gnu environment we have as result that 78 tests failed, some are related to an Internal compiler error on the same file:
Internal compiler error in classify_argument, at config/i386/i386.c:1841
This internal compiler error was detected also compiling some of our own pascal modules ported under gpc.
In attachment you find included the gpc testsuite log file.
Some advise?
Regards.
Angelo Fumagalli
Hello,
Angelo Fumagalli wrote:
running gpc testsuite (gpc version 20041218, based on gcc-3.2.3) on x86_64-unknown-linux-gnu environment we have as result that 78 tests failed, some are related to an Internal compiler error on the same file:
Internal compiler error in classify_argument, at config/i386/i386.c:1841
This internal compiler error was detected also compiling some of our own pascal modules ported under gpc.
In attachment you find included the gpc testsuite log file.
Some advise?
Regards.
Angelo Fumagalli
I suggest moving to later backend (3.3.5 or 3.4.3). gcc-3.2.3 on amd64 has serious problems. With some effort the problem metioned above could be fixed, but other bugs are likely to hit later.
Hello,
to solve this internal error we passed to the last gpc version (gpc version 20050331, based on gcc-3.4.3) but unfortunately we got another unexpected problem related to "global" procedures names that have been changed respect the gpc 20041218. In fact the gpc 20050331 change the internal name of "global" procedures adding a variable prefix as, for examèple, "_p_Mx_modulename_Sy_procedurename" instead the original "procedurename". For us this change loads big problem because, our pascal modules come from VAX/VMS and are structured to be exported as object library containing thousand of modules and some environment modules to be used as interface by application pascal modules. We have a lot of applicatons and the related pascal modules cannot use internal library modules as interface because don't know them but know only some (2 or 3) "library interface modules". So, porting our pascal modules under gpc the choise was to maintaining the original modules structures in terms of files, so we create the related gpc modules containing the proper interface to resolve the references to the library procedures, types and variables. The work around, to avoid gpc compilation errors, was to write procedure declarations using the "external name" extension, for example:
unit lbbe, interface procedure ios_txt_open (var f: text); external name 'Ios_txt_open'; procedure ios_txt_close (var f: text); external name 'Ios_txt_close'; /* other hundred and hundred of procedure declarations */
end.
Using gpc20050331 this approch don't work any more. The question is, there is a gpc option in order to disable this name building method or could you describe us this procedure name building algoritm? Thank you very much in advance for your help.
Angelo Fumagalli
___________________________________________________________ ----- Original Message ----- From: "Waldek Hebisch" hebisch@math.uni.wroc.pl To: gpc@gnu.de Sent: Wednesday, May 04, 2005 4:18 PM Subject: Re: Internal gpc compiler error
Hello,
Angelo Fumagalli wrote:
running gpc testsuite (gpc version 20041218, based on gcc-3.2.3) on x86_64-unknown-linux-gnu environment we have as result that 78 tests
failed,
some are related to an Internal compiler error on the same file:
Internal compiler error in classify_argument, at config/i386/i386.c:1841
This internal compiler error was detected also compiling some of our own pascal modules ported under gpc.
In attachment you find included the gpc testsuite log file.
Some advise?
Regards.
Angelo FumagalliI suggest moving to later backend (3.3.5 or 3.4.3). gcc-3.2.3 on amd64 has serious problems. With some effort the problem metioned above could be fixed, but other bugs are likely to hit later.
-- Waldek Hebisch hebisch@math.uni.wroc.pl
Angelo.Fumagalli@alcatel.it wrote:
to solve this internal error we passed to the last gpc version (gpc version 20050331, based on gcc-3.4.3) but unfortunately we got another unexpected problem related to "global" procedures names that have been changed respect the gpc 20041218. In fact the gpc 20050331 change the internal name of "global" procedures adding a variable prefix as, for examÚple, "_p_Mx_modulename_Sy_procedurename" instead the original "procedurename". For us this change loads big problem because, our pascal modules come from VAX/VMS and are structured to be exported as object library containing thousand of modules and some environment modules to be used as interface by application pascal modules. We have a lot of applicatons and the related pascal modules cannot use internal library modules as interface because don't know them but know only some (2 or 3) "library interface modules". So, porting our pascal modules under gpc the choise was to maintaining the original modules structures in terms of files, so we create the related gpc modules containing the proper interface to resolve the references to the library procedures, types and variables. The work around, to avoid gpc compilation errors, was to write procedure declarations using the "external name" extension, for example:
unit lbbe, interface procedure ios_txt_open (var f: text); external name 'Ios_txt_open'; procedure ios_txt_close (var f: text); external name 'Ios_txt_close'; /* other hundred and hundred of procedure declarations */
end.
Using gpc20050331 this approch don't work any more.
Relying on the default linker names was never reliable. The change you mention was *necessary* to implement qualified identifiers. This has been discussed here rather often. The reliable way to use linker names (if you can't use proper units or modules, which would be much simpler, for whatever reasons) is to declare the linker names where the routines are declared:
procedure ios_txt_open (var f: text); attribute (name = 'Ios_txt_open'); begin ... end;
Note, the respective changes were made in gpc-20030323, so there really was enough time for a "soft migration". Now, unfortunately, you might be forced to rush through it ...
The question is, there is a gpc option in order to disable this name building method
As I wrote above, it's not possible since identical identifiers in different modules would conflict on the linker level then.
or could you describe us this procedure name building algoritm?
We could, but I think we better didn't. ;-) Changing to the new names means just waiting for the next accident to happen. Declaring linker names or using proper units/modules will solve the problem once and forever, even if the default linker names will change again.
Frank
Angelo FUMAGALLI wrote:
Hello,
to solve this internal error we passed to the last gpc version (gpc version 20050331, based on gcc-3.4.3) but unfortunately we got another unexpected problem related to "global" procedures names that have been changed respect the gpc 20041218. In fact the gpc 20050331 change the internal name of "global" procedures adding a variable prefix as, for exam?ple, "_p_Mx_modulename_Sy_procedurename" instead the original "procedurename". For us this change loads big problem because, our pascal modules come from VAX/VMS and are structured to be exported as object library containing thousand of modules and some environment modules to be used as interface by application pascal modules. We have a lot of applicatons and the related pascal modules cannot use internal library modules as interface because don't know them but know only some (2 or 3) "library interface modules". So, porting our pascal modules under gpc the choise was to maintaining the original modules structures in terms of files, so we create the related gpc modules containing the proper interface to resolve the references to the library procedures, types and variables.
gpc allows reexport, so you can easily create "library interface modules" just using official methods. Namely,
module lib_int; export lib_int = (fun1, fun2); import lib1; lib2; end; end .
gives you interface to the library consisting of two modules: `lib1' and `lib2' (assuming that `lib1' implements function `fun1' and `lib2' implements function `fun2'). This form is quite flexible, you can specify which functions (types, constants, variables) you want to export and you can re-name them if you wish.
There is also a shortcut, if you write:
module lib_int2; export lib_int2 = all; import lib1; lib2; end; end .
and compile `lib_int2' using `-fpropagate-units' option, then `lib_int2' will automatically re-export all functions, types, constants and variables defined in `lib1' and `lib2'.
The first method requires the interface module to be EP module. The shortcut also works if the interface module actually is a unit.
--- Waldek Hebisch hebisch@math.uni.wroc.pl
Running the testsuite of GPC (gpc version 20050331, based on gcc-3.4.3) on x86_64_unknown-linux-gnu platform we got the same segmentation fault on both traptest modules (traptest.pas & trap2test.pas). It seems that on the trapexec mechanism dosn't work correctly. We got the same problem also on our application ported under gpc. Same suggestions to solve this problem?
Here, below, you find the problem report.
-bash-2.05b$ gpc -g -O3 -W -Wall --autobuild -o traptest.exe traptest.pas -bash-2.05b$ ./traptest.exe Segmentation fault -bash-2.05b$ gdb traptest.exe (gdb) run Starting program: /dkalvn46_1/grfdev/ags/gnu/gpc-20050331/p/test/traptest.exe
Program received signal SIGSEGV, Segmentation fault. $0000007fbffff010 in ?? () (gdb) where #0 $0000007fbffff010 in ?? () #1 $0000000000402ad9 in dosetjmp (p=$7fbffff010) at /dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trapc. c:50 #2 $0000000000402c13 in _p__M4_Trap_S3_Trapexec (p=@$402e20) at /dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trap.p as:173 #3 $0000000000402f2e in main program () at traptest.pas:25 #4 $0000000000402fdc in main (argc=0, argv=$0, envp=$7fbfffef20) at <implicit code>:31 (gdb)
*** traptest.pas ****
1 { Test of the Trap unit. } 2 program TrapTest; 3 uses Trap; 4 procedure Test (Trapped : Boolean); 5 var Counter : Integer = 0; attribute (static); 6 begin 7 if Trapped then 8 begin 9 Inc (Counter); 10 if Counter < 42 then 11 Write (Ln (0)) 12 else 13 Write ('K') 14 end 15 else 16 begin 17 Write ('O'); 18 Write (Ln (0)) 19 end 20 end; 21 begin 22 TrapExec (Test); 23 TrappedExitCode := 0; 24 TrappedErrorAddr := nil; 25 TrappedErrorMessageString := ''; 26 WriteLn 27 end.
Running the testsuite of GPC (gpc version 20050331, based on gcc-3.4.3) on x86_64_unknown-linux-gnu platform we got the same segmentation fault on both traptest modules (traptest.pas & trap2test.pas). It seems that on the trapexec mechanism dosn't work correctly. We got the same problem also on our application ported under gpc. Same suggestions to solve this problem?
Here, below, you find the problem report.
-bash-2.05b$ gpc -g -O3 -W -Wall --autobuild -o traptest.exe traptest.pas -bash-2.05b$ ./traptest.exe Segmentation fault -bash-2.05b$ gdb traptest.exe (gdb) run Starting program: /dkalvn46_1/grfdev/ags/gnu/gpc-20050331/p/test/traptest.exe
Program received signal SIGSEGV, Segmentation fault. $0000007fbffff010 in ?? () (gdb) where #0 $0000007fbffff010 in ?? () #1 $0000000000402ad9 in dosetjmp (p=$7fbffff010) at /dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trapc. c:50 #2 $0000000000402c13 in _p__M4_Trap_S3_Trapexec (p=@$402e20) at /dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trap.p as:173 #3 $0000000000402f2e in main program () at traptest.pas:25 #4 $0000000000402fdc in main (argc=0, argv=$0, envp=$7fbfffef20) at <implicit code>:31 (gdb)
You did not tell us which distribution you are running. I can only guess that problem may be related to stack execute protection. To call local procedures via procedural parameters gpc generates small hunks of code (called trampolines) on the stack. Gpc is doing `mprotect' system call to make stack executable, but some distribution do not honor this.
If this is the case a few of other tests will also fail (there is a number of test failures due to wrong tests, so you may have lost essential failures in the noise).
As a workaround you can try to modify the trap unit so that the `DoCall' procedure is no longer local.
As I wrote you in my previous e-mail we are running the testsuite (p/test) of gpc-20050331 based on gcc-3.4.3 under the "x86_64_unknown-linux-gnu" platform, so we are using gpc-20050331 and gcc-3.4.3. Anyway, as you can see in the previous message we have isolated the trap problem, compiling and running the traptest modules alone in order to avoid noise by other test cases. Anyway we won't change the trapc.c or trap.pas source code because such modules are contained in the GPC distribution kit , so we think that this task is of only relevance of the pascal development team.
If it can help you better, here, below, you find a full stack status report.
(gdb) run Starting program: /dkalvn46_1/grfdev/ags/gnu/gpc-20050331/p/test/traptest.exe
Program received signal SIGSEGV, Segmentation fault. $0000007fbffff010 in ?? () (gdb) where full #0 $0000007fbffff010 in ?? () No symbol table info available. #1 $0000000000402ad9 in dosetjmp (p=$7fbffff010) at /dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trapc. c:50 prev = {buf = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}}} #2 $0000000000402c13 in _p__M4_Trap_S3_Trapexec (p=@$402e20) at /dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trap.p as:173 SavedTrappedExitCode = 0 SavedTrappedErrorAddr = (^pointer) $0 SavedTrappedErrorMessageString = '' #3 $0000000000402f2e in main program () at traptest.pas:25 No locals. #4 $0000000000402fdc in main (argc=0, argv=$0, envp=$7fbfffef20) at <implicit code>:31 (gdb)
Angelo Fumagalli ___________________________________________________________________ ----- Original Message ----- From: "Waldek Hebisch" hebisch@math.uni.wroc.pl To: gpc@gnu.de Sent: Monday, May 16, 2005 5:13 PM Subject: Re: Trapexec segmentation fault
Running the testsuite of GPC (gpc version 20050331, based on gcc-3.4.3)
on
x86_64_unknown-linux-gnu platform we got the same segmentation fault on
both
traptest modules (traptest.pas & trap2test.pas). It seems that on the trapexec mechanism dosn't work correctly. We got the same problem also on our application ported under gpc. Same suggestions to solve this problem?
Here, below, you find the problem report.
-bash-2.05b$ gpc -g -O3 -W -Wall --autobuild -o traptest.exe
traptest.pas
-bash-2.05b$ ./traptest.exe Segmentation fault -bash-2.05b$ gdb traptest.exe (gdb) run Starting program: /dkalvn46_1/grfdev/ags/gnu/gpc-20050331/p/test/traptest.exe
Program received signal SIGSEGV, Segmentation fault. $0000007fbffff010 in ?? () (gdb) where #0 $0000007fbffff010 in ?? () #1 $0000000000402ad9 in dosetjmp (p=$7fbffff010) at
/dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trapc.
c:50 #2 $0000000000402c13 in _p__M4_Trap_S3_Trapexec (p=@$402e20) at
/dkalvn46_1/grfdev/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/units/trap.p
as:173 #3 $0000000000402f2e in main program () at traptest.pas:25 #4 $0000000000402fdc in main (argc=0, argv=$0, envp=$7fbfffef20) at <implicit code>:31 (gdb)
You did not tell us which distribution you are running. I can only guess that problem may be related to stack execute protection. To call local procedures via procedural parameters gpc generates small hunks of code (called trampolines) on the stack. Gpc is doing `mprotect' system call to make stack executable, but some distribution do not honor this.
If this is the case a few of other tests will also fail (there is a number of test failures due to wrong tests, so you may have lost essential failures in the noise).
As a workaround you can try to modify the trap unit so that the `DoCall' procedure is no longer local.
-- Waldek Hebisch hebisch@math.uni.wroc.pl
As I wrote you in my previous e-mail we are running the testsuite (p/test) of gpc-20050331 based on gcc-3.4.3 under the "x86_64_unknown-linux-gnu" platform, so we are using gpc-20050331 and gcc-3.4.3. Anyway, as you can see in the previous message we have isolated the trap problem, compiling and running the traptest modules alone in order to avoid noise by other test cases. Anyway we won't change the trapc.c or trap.pas source code because such modules are contained in the GPC distribution kit , so we think that this task is of only relevance of the pascal development team.
I was not clear enough in the previous message: the `traptest.pas' test runs fine on my AMD64 Mandrake 9.2. So, the problem is still not "isolated", I am trying to find out why your machine works differently.
Also, since I can not reproduce the problem I am dependent on information that you provide.
As I wrote, my guess is that the failure is due to the stack protection (Mandrake 9.2 uses no stack protection, newer distributions may add it). ATM you have not provided enough detail to verify this.
If it can help you better, here, below, you find a full stack status report.
(gdb) run Starting program: /dkalvn46_1/grfdev/ags/gnu/gpc-20050331/p/test/traptest.exe
Program received signal SIGSEGV, Segmentation fault. $0000007fbffff010 in ?? ()
Could you verify that the trampoline code got correctly planted on the stack, using `disassemble 0x7fbffff010 7fbffff030'. You should get something like
Dump of assembler code from 0x7fbfffeef0 to 0x7fbfffef10: 0x0000007fbfffeef0: mov $0x402b40,%r11d 0x0000007fbfffeef6: mov $0x7fbffff730,%r10 0x0000007fbfffef00: jmpq *%r11 0x0000007fbfffef03: add %al,(%rax)
(that is dump from my machine, on your machine addreses will differ.
Also `info registers' can show if the code is really on the stack.
If the problem is caused by executable stack the patch below should work aroud the problem:
--- p/units/trap.pas.orig 2005-05-16 19:38:59.460127184 +0200 +++ p/units/trap.pas 2005-05-16 19:50:40.088615464 +0200 @@ -140,6 +140,18 @@ end end;
+{$ifndef NEW_TRAP} +var + TrapP: ^procedure (Trapped: Boolean) = nil; + +procedure DoCall (Trapped: Boolean); +begin + AtExit (TrapExit); + TrapP^ (Trapped) + end; +{$endif} + + procedure TrapExec (procedure p (Trapped: Boolean)); var SavedTrappedExitCode: Integer { @@ } = 0; @@ -157,12 +169,8 @@ goto TrapLabel end; {$else} + SavedTrapP: ^procedure (Trapped: Boolean) = nil;
- procedure DoCall (Trapped: Boolean); - begin - AtExit (TrapExit); - p (Trapped) - end; {$endif}
begin @@ -179,7 +187,10 @@ p (Trapped); TrapJump := SavedTrapJump; {$else} + SavedTrapP := TrapP; + TrapP := @p; DoSetJmp (DoCall); + TrapP := SavedTrapP; {$endif} Dec (TrapCount); if TrappedErrorAddr = nil then
-
Angelo.Fumagalli＠alcatel.it -
Frank Heckenbach -
Waldek Hebisch