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