Hi all,
I am sorry to be back on this subject after a so long time, but I just hit the problem with a real-life program. I applied the patch you suggested and ran the gpc test suite again. It gives worse results than previously with 97 unexpected failures.
If I run some programs under gdb I get Segmentation faults in various places in sets.pas. For example SetCopy (line 286) adam3g adam3h assumptions awindte2 awindtes dostest SetEqual (line 215) adam3k adam3l adam3m adam3n WordNumber (line 113) adam3q adam3r ancestor2 Test fail with no core dump az44 chief41 couper10 couper8 gpc gives: warning: `absolute' declaration increases required alignment and test fail chris4 chris5
Is there a patch to solve this problem? If you need more information, I will do my best to give it.
Regards
Pascal Viandier pascal@accovia.com
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Waldek Hebisch Envoyé : May 25, 2005 16:33 À : gpc@gnu.de Objet : Re: RE : bigsetdemo strange result
Pascal Viandier wrote:
Hi,
At your suggestion, I ran the gpc test suite. Here is the summary result:
Test Run By pascal on 2005-05-25 10:45:41 Native configuration is sparc-sun-solaris2.6 (perfdev) gpc 20050331, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused
Nuber of tests: 4947 Number of Ok: 4828 Number of tests skipped: 7 Number of failures: 56 (includes internal compiler error and some coredumps) Number of coredumps: 47 Number of compiler errors: 2
Should I worry?
Something is really broken. At first glance all failures involve sets, so it may be just a single problem.
Pascal Viandier wrote:
I am sorry to be back on this subject after a so long time, but I just hit the problem with a real-life program. I applied the patch you suggested and ran the gpc test suite again. It gives worse results than previously with 97 unexpected failures.
If I run some programs under gdb I get Segmentation faults in various places in sets.pas. For example SetCopy (line 286) adam3g adam3h assumptions awindte2 awindtes dostest SetEqual (line 215) adam3k adam3l adam3m adam3n WordNumber (line 113) adam3q adam3r ancestor2 Test fail with no core dump az44 chief41 couper10 couper8 gpc gives: warning: `absolute' declaration increases required alignment and test fail chris4 chris5
Is there a patch to solve this problem? If you need more information, I will do my best to give it.
FYI: I did run the test suite on Solaris 2.6 with the sets patch applied and all set test run fine (there were two test failures concerning packed arrays). So the problem is triggered by same specific detail of your configuration (exact versions of software, configure options, shell, assembler and linker etc...).
ATM our Solaris is down so I can not test directly. To get more information one can type `info registers' and `dissasemble' at the point of crash.
It would help if you can narrow down the problem: does it occur also is all sets are variable or only if one of the arguments is constant. Also when comparing sets the compiler is doing exivalent of:
type Plong = ^MedCard; .... if SetEqual(Plong(@s1), Plong(@s2)) then...
It would be nice to have a testcase does not use the runtime, but just its own copy of SetEqual.
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Waldek Hebisch Envoyé : December 5, 2005 13:40 À : gpc@gnu.de Objet : Re: Crash with sets under Solaris
I gathered all the details I could. The versions of the components: ------------------------------- gpc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.6/3.4.3/specs Configured with: ../gcc-3.4.3/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=pascal,c,c++ Thread model: posix gpc version 20050331, based on gcc-3.4.3
as -V as: WorkShop Compilers 4.X dev 18 Sep 1996
ld -V ld: Software Generation Utilities - Solaris-ELF (4.0)
The test program: ----------------- It is a variation on the adam3k program from the gpc test suite:
program adam3k2; const sconst = [3,5]; var s : set of 1..10; s2 : set of 1..10 = [3,5]; begin s := [3,5]; if s = s2 then WriteLn ('OK') else WriteLn ('failed'); if s = sconst then WriteLn ('OK') else WriteLn ('failed'); end.
I compile it with: gpc -g -O0 --automake -o adam3k2 adam3k2.pas
Results: -------- There are four interesting points here: 1- If I execute it as it is, there is no core dump but both tests display "failed" instead of "OK" 2- If I swap the two tests (put "if s = s2..." after "if s = sconst...") the test crashes on the first comparison in _p_Set_Equal. 3- The optimization level at the gpc command-line (-O0) has no impact on the result 4- (Perhaps useless) Swapping the operands of the tests has no impact on the result.
What gdb says: Starting program: /data1/Pascal/p/test/adam3k2
Program received signal SIGSEGV, Segmentation fault. $00029134 in _p_Set_Equal (Seta=$55d84, Lowa=0, Higha=1312, Setb=$41c62, Lowb=3, Highb=0) at /data1/Pascal/gcc-3.4.3/gcc/p/rts/sets.pas:215 215 if SetA^[i + a] <> SetB^[i] then Exit; (gdb) list 210 wa := WordNumber (HighA, LowA); 211 wb := WordNumber (HighB, LowB); 212 for i := 0 to a - 1 do 213 if SetA^[i] <> 0 then Exit; 214 for i := 0 to Min (wa - a, wb) do 215 if SetA^[i + a] <> SetB^[i] then Exit; 216 for i := wa - a + 1 to wb do 217 if SetB^[i] <> 0 then Exit; 218 SetEqual := True 219 end (gdb) info registers g0 $0 0 g1 $0 0 g2 $effff730 -268437712 g3 $0 0 g4 $0 0 g5 $0 0 g6 $0 0 g7 $0 0 o0 $55d84 351620 o1 $0 0 o2 $0 0 o3 $0 0 o4 $ffffffff -1 o5 $520 1312 sp $effff890 4026529936 o7 $18058 98392 l0 $0 0 l1 $0 0 l2 $22 34 l3 $56400 353280 l4 $3fffffe 67108862 l5 $23 35 l6 $0 0 l7 $0 0 i0 $0 0 i1 $1 1 i2 $0 0 i3 $41c62 269410 i4 $3 3 i5 $0 0 fp $effff900 4026530048 i7 $180c4 98500 y $0 0 psr $fe400005 -29360123 icc:-Z--, pil:0, s:0, ps:0, et:0, cwp:5 wim $0 0 tbr $0 0 pc $29134 168244 npc $29138 168248 fpsr $0 0 rd:N, tem:0, ns:0, ver:0, ftt:0, qne:0, fcc:=, aexc:0, cexc:0 cpsr $0 0 (gdb) disassemble Dump of assembler code for function _p_Set_Equal: $00029084 <_p_Set_Equal+0>: save %sp, -112, %sp $00029088 <_p_Set_Equal+4>: mov %i1, %o1 $0002908c <_p_Set_Equal+8>: mov %i0, %o0 $00029090 <_p_Set_Equal+12>: mov %i2, %o5 $00029094 <_p_Set_Equal+16>: cmp %i1, %i5 $00029098 <_p_Set_Equal+20>: bg $290a4 <_p_Set_Equal+32> $0002909c <_p_Set_Equal+24>: mov 1, %g1 $000290a0 <_p_Set_Equal+28>: clr %g1 $000290a4 <_p_Set_Equal+32>: btst 0xff, %g1 $000290a8 <_p_Set_Equal+36>: bne $29188 <_p_Set_Equal+260> $000290ac <_p_Set_Equal+40>: cmp %i4, %o5 $000290b0 <_p_Set_Equal+44>: bg $29188 <_p_Set_Equal+260> $000290b4 <_p_Set_Equal+48>: sra %o1, 5, %i2 $000290b8 <_p_Set_Equal+52>: sra %i4, 5, %o2 $000290bc <_p_Set_Equal+56>: cmp %i2, %o2 $000290c0 <_p_Set_Equal+60>: bg $291b8 <_p_Set_Equal+308> $000290c4 <_p_Set_Equal+64>: clr %i0 $000290c8 <_p_Set_Equal+68>: sra %o5, 5, %g1 $000290cc <_p_Set_Equal+72>: sub %o2, %i2, %o1 $000290d0 <_p_Set_Equal+76>: sra %i5, 5, %o5 $000290d4 <_p_Set_Equal+80>: sub %g1, %i2, %i2 $000290d8 <_p_Set_Equal+84>: addcc %o1, -1, %o4 $000290dc <_p_Set_Equal+88>: bneg $29104 <_p_Set_Equal+128> $000290e0 <_p_Set_Equal+92>: sub %o5, %o2, %i5 $000290e4 <_p_Set_Equal+96>: clr %o2 $000290e8 <_p_Set_Equal+100>: sll %o2, 2, %g1 $000290ec <_p_Set_Equal+104>: ld [ %o0 + %g1 ], %o5 $000290f0 <_p_Set_Equal+108>: cmp %o5, 0 $000290f4 <_p_Set_Equal+112>: bne $291dc <_p_Set_Equal+344> $000290f8 <_p_Set_Equal+116>: cmp %o2, %o4 $000290fc <_p_Set_Equal+120>: bl $290e8 <_p_Set_Equal+100> $00029100 <_p_Set_Equal+124>: inc %o2 $00029104 <_p_Set_Equal+128>: sub %i2, %o1, %i2 $00029108 <_p_Set_Equal+132>: cmp %i2, %i5 $0002910c <_p_Set_Equal+136>: ble $29118 <_p_Set_Equal+148> $00029110 <_p_Set_Equal+140>: mov %i2, %o3 $00029114 <_p_Set_Equal+144>: mov %i5, %o3 $00029118 <_p_Set_Equal+148>: cmp %o3, 0 $0002911c <_p_Set_Equal+152>: bl $29150 <_p_Set_Equal+204> $00029120 <_p_Set_Equal+156>: sll %o1, 2, %g1 $00029124 <_p_Set_Equal+160>: add %g1, %o0, %o0 $00029128 <_p_Set_Equal+164>: clr %o2 $0002912c <_p_Set_Equal+168>: sll %o2, 2, %g1 $00029130 <_p_Set_Equal+172>: ld [ %o0 ], %o5 $00029134 <_p_Set_Equal+176>: ld [ %i3 + %g1 ], %o4 $00029138 <_p_Set_Equal+180>: cmp %o5, %o4 $0002913c <_p_Set_Equal+184>: bne $291dc <_p_Set_Equal+344> $00029140 <_p_Set_Equal+188>: add %o0, 4, %o0 $00029144 <_p_Set_Equal+192>: cmp %o2, %o3 $00029148 <_p_Set_Equal+196>: bl $2912c <_p_Set_Equal+168> $0002914c <_p_Set_Equal+200>: inc %o2 $00029150 <_p_Set_Equal+204>: add %i2, 1, %g1 $00029154 <_p_Set_Equal+208>: cmp %g1, %i5 $00029158 <_p_Set_Equal+212>: bg,a $291dc <_p_Set_Equal+344> $0002915c <_p_Set_Equal+216>: mov 1, %i0 $00029160 <_p_Set_Equal+220>: mov %g1, %o2 $00029164 <_p_Set_Equal+224>: sll %o2, 2, %g1 $00029168 <_p_Set_Equal+228>: ld [ %i3 + %g1 ], %o5 $0002916c <_p_Set_Equal+232>: cmp %o5, 0 $00029170 <_p_Set_Equal+236>: bne $291dc <_p_Set_Equal+344> $00029174 <_p_Set_Equal+240>: cmp %o2, %i5 $00029178 <_p_Set_Equal+244>: bl $29164 <_p_Set_Equal+224> $0002917c <_p_Set_Equal+248>: inc %o2 $00029180 <_p_Set_Equal+252>: b $291dc <_p_Set_Equal+344> $00029184 <_p_Set_Equal+256>: mov 1, %i0 $00029188 <_p_Set_Equal+260>: call $29038 <_p_Set_IsEmpty> $0002918c <_p_Set_Equal+264>: mov %o5, %o2 $00029190 <_p_Set_Equal+268>: btst 0xff, %o0 $00029194 <_p_Set_Equal+272>: bne,a $291a4 <_p_Set_Equal+288> $00029198 <_p_Set_Equal+276>: mov %i3, %o0 $0002919c <_p_Set_Equal+280>: b $291dc <_p_Set_Equal+344> $000291a0 <_p_Set_Equal+284>: mov %o0, %i0 $000291a4 <_p_Set_Equal+288>: mov %i4, %o1 $000291a8 <_p_Set_Equal+292>: call $29038 <_p_Set_IsEmpty> $000291ac <_p_Set_Equal+296>: mov %i5, %o2 $000291b0 <_p_Set_Equal+300>: b $291dc <_p_Set_Equal+344> $000291b4 <_p_Set_Equal+304>: mov %o0, %i0 $000291b8 <_p_Set_Equal+308>: mov %o5, %o4 $000291bc <_p_Set_Equal+312>: mov %o0, %g1 $000291c0 <_p_Set_Equal+316>: mov %i5, %o5 $000291c4 <_p_Set_Equal+320>: mov %i3, %o0 $000291c8 <_p_Set_Equal+324>: mov %o2, %i2 $000291cc <_p_Set_Equal+328>: mov %o4, %i5 $000291d0 <_p_Set_Equal+332>: mov %g1, %i3 $000291d4 <_p_Set_Equal+336>: b $290c8 <_p_Set_Equal+68> $000291d8 <_p_Set_Equal+340>: sra %o1, 5, %o2 $000291dc <_p_Set_Equal+344>: ret $000291e0 <_p_Set_Equal+348>: restore End of assembler dump. (gdb)
Regards
Pascal Viandier pascal@accovia.com
Pascal Viandier wrote:
I gathered all the details I could. The versions of the components:
gpc -v Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.6/3.4.3/specs Configured with: ../gcc-3.4.3/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=pascal,c,c++ Thread model: posix gpc version 20050331, based on gcc-3.4.3
as -V as: WorkShop Compilers 4.X dev 18 Sep 1996
ld -V ld: Software Generation Utilities - Solaris-ELF (4.0)
That may be the difference. IIRC I used Gnu assembler and linker (and I have different versions of Sun tools).
The test program:
It is a variation on the adam3k program from the gpc test suite:
program adam3k2; const sconst = [3,5]; var s : set of 1..10; s2 : set of 1..10 = [3,5]; begin s := [3,5]; if s = s2 then WriteLn ('OK') else WriteLn ('failed'); if s = sconst then WriteLn ('OK') else WriteLn ('failed'); end.
I compile it with: gpc -g -O0 --automake -o adam3k2 adam3k2.pas
Results:
There are four interesting points here: 1- If I execute it as it is, there is no core dump but both tests display "failed" instead of "OK" 2- If I swap the two tests (put "if s = s2..." after "if s = sconst...") the test crashes on the first comparison in _p_Set_Equal. 3- The optimization level at the gpc command-line (-O0) has no impact on the result 4- (Perhaps useless) Swapping the operands of the tests has no impact on the result.
What gdb says: Starting program: /data1/Pascal/p/test/adam3k2
Program received signal SIGSEGV, Segmentation fault. $00029134 in _p_Set_Equal (Seta=$55d84, Lowa=0, Higha=1312, Setb=$41c62, Lowb=3, Highb=0)
That shows paramteters at the point of crash (where they changed by the execution). Can you put a breakpoint at _p_Set_Equal and check if parameters are correct: both Seta nad Setb should point to number 40. BTW: to get correct values on my machine I had to setep trough few instructions (so that parameters are copied to their registers) and then do:
set language c print *(long *)SetA
(I am not sure if Pascal mode in gdb allows one to cast values to unnamed type).
If the paramters are incorrect then one should egzamine assembly file obtained via `gpc -g -S adam3k2.pas'. However, the file I got from the cross compiler looks OK, so the most likely reason is assembler or linker.
(gdb) disassemble
The code looks OK (my first guess was that SetEqual got miscompiled). And after reassembling it runs correctly in an emulator. Also, I get the same code from the cross compiler.
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Waldek Hebisch Envoyé : December 7, 2005 07:57 À : gpc@gnu.de Objet : Re: RE : Crash with sets under Solaris
<snip>
That may be the difference. IIRC I used Gnu assembler and linker (and I have different versions of Sun tools).
If I remember well, the instructions to build gpc say to avoid GNU assembler and linker under Solaris. That's why I did not use them.
The test program:
<snip>
Program received signal SIGSEGV, Segmentation fault. $00029134 in _p_Set_Equal (Seta=$55d84, Lowa=0, Higha=1312, Setb=$41c62, Lowb=3, Highb=0)
That shows paramteters at the point of crash (where they changed by the execution). Can you put a breakpoint at _p_Set_Equal and check if parameters are correct: both Seta nad Setb should point to number 40.
A bit far from 40: (gdb) p *(long *) Seta $4 = 83886080 (gdb) p *(long *) Setb $3 = 1280
If the paramters are incorrect then one should egzamine assembly file obtained via `gpc -g -S adam3k2.pas'.
Here it is:
.file "adam3k2.pas" .stabs "/data1/Pascal/p/test/",100,0,0,.LLtext0 .stabs "adam3k2.pas",100,0,0,.LLtext0 .section ".text" .LLtext0: .stabs "gcc2_compiled.",60,0,0,0 .stabs "Integer:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0 .stabs "Cardinal:t(0,2)=r(0,2);0000000000000;0037777777777;",128,0,0,0 .stabs "Word:t(0,3)=r(0,3);0000000000000;0037777777777;",128,0,0,0 .stabs "Cinteger:t(0,4)=r(0,4);-2147483648;2147483647;",128,0,0,0 .stabs "Ccardinal:t(0,5)=r(0,5);0000000000000;0037777777777;",128,0,0,0 .stabs "Cword:t(0,6)=r(0,6);0000000000000;0037777777777;",128,0,0,0 .stabs "Byteint:t(0,7)=@s8;r(0,7);-128;127;",128,0,0,0 .stabs "Bytecard:t(0,8)=@s8;r(0,8);0;255;",128,0,0,0 .stabs "Byte:t(0,9)=@s8;r(0,9);0;255;",128,0,0,0 .stabs "Shortint:t(0,10)=@s16;r(0,10);-32768;32767;",128,0,0,0 .stabs "Smallint:t(0,11)=@s16;r(0,11);-32768;32767;",128,0,0,0 .stabs "Shortcard:t(0,12)=@s16;r(0,12);0;65535;",128,0,0,0 .stabs "Shortword:t(0,13)=@s16;r(0,13);0;65535;",128,0,0,0 .stabs "Medint:t(0,14)=r(0,14);-2147483648;2147483647;",128,0,0,0 .stabs "Medcard:t(0,15)=r(0,15);0000000000000;0037777777777;",128,0,0,0 .stabs "Medword:t(0,16)=r(0,16);0000000000000;0037777777777;",128,0,0,0 .stabs "Longestint:t(0,17)=@s64;r(0,17);01000000000000000000000;0777777777777777777 777;",128,0,0,0 .stabs "Longint:t(0,18)=@s64;r(0,18);01000000000000000000000;0777777777777777777777 ;",128,0,0,0 .stabs "Comp:t(0,19)=@s64;r(0,19);01000000000000000000000;0777777777777777777777;", 128,0,0,0 .stabs "Longestcard:t(0,20)=@s64;r(0,20);0000000000000;01777777777777777777777;",12 8,0,0,0 .stabs "Longestword:t(0,21)=@s64;r(0,21);0000000000000;01777777777777777777777;",12 8,0,0,0 .stabs "Longcard:t(0,22)=@s64;r(0,22);0000000000000;01777777777777777777777;",128,0 ,0,0 .stabs "Longword:t(0,23)=@s64;r(0,23);0000000000000;01777777777777777777777;",128,0 ,0,0 .stabs "Sizetype:t(0,24)=r(0,24);0000000000000;0037777777777;",128,0,0,0 .stabs "Ptrint:t(0,25)=r(0,25);-2147483648;2147483647;",128,0,0,0 .stabs "Ptrcard:t(0,26)=r(0,26);0000000000000;0037777777777;",128,0,0,0 .stabs "Ptrword:t(0,27)=r(0,27);0000000000000;0037777777777;",128,0,0,0 .stabs "Ptrdifftype:t(0,28)=r(0,28);-2147483648;2147483647;",128,0,0,0 .stabs "Shortreal:t(0,29)=r(0,0);4;0;",128,0,0,0 .stabs "Single:t(0,30)=r(0,0);4;0;",128,0,0,0 .stabs "Real:t(0,31)=r(0,0);8;0;",128,0,0,0 .stabs "Medreal:t(0,32)=r(0,0);8;0;",128,0,0,0 .stabs "Double:t(0,33)=r(0,0);8;0;",128,0,0,0 .stabs "Longreal:t(0,34)=r(0,0);16;0;",128,0,0,0 .stabs "Longestreal:t(0,35)=r(0,0);16;0;",128,0,0,0 .stabs "Extended:t(0,36)=r(0,0);16;0;",128,0,0,0 .stabs "Complex:t(0,37)=R3;16;0;",128,0,0,0 .stabs "Boolean:t(0,38)=@s8;-16",128,0,0,0 .stabs "Bytebool:t(0,39)=@s8;-16",128,0,0,0 .stabs "Shortbool:t(0,40)=@s16;-16",128,0,0,0 .stabs "Wordbool:t(0,41)=@s32;-16",128,0,0,0 .stabs "Medbool:t(0,42)=@s32;-16",128,0,0,0 .stabs "Longbool:t(0,43)=@s64;-16",128,0,0,0 .stabs "Longestbool:t(0,44)=@s64;-16",128,0,0,0 .stabs "Cboolean:t(0,45)=@s8;-16",128,0,0,0 .stabs "Void:t(0,46)=(0,46)",128,0,0,0 .stabs "Char:t(0,47)=@s8;-20",128,0,0,0 .stabs "Ansichar:t(0,48)=@s8;-20",128,0,0,0 .stabs "Cstring:t(0,49)=*(0,50)=@s8;-20",128,0,0,0 .stabs "Pchar:t(0,51)=*(0,50)",128,0,0,0 .stabs "Pansichar:t(0,52)=*(0,50)",128,0,0,0 .stabs "Pointer:t(0,53)=*(0,46)",128,0,0,0 .stabs "Pobjecttype:t(0,54)=*(0,55)=s16Size:(0,15),0,32;Negatedsize:(0,14),32,32;Pa rent:(0,54),64,32;Name:(0,56)=*(0,57)=k(0,58)=s12Capacity:(0,2),0,32;length: (0,2),32,32;_p_Schema_:(0,59)=ar(0,1);1;1;(0,50),64,8;;,96,32;;",128,0,0,0 .stabs "String:t(0,58)",128,0,0,0 .stabs "Text:t(0,60)=s4_p_File_:(0,53),0,32;;",128,0,0,0 .stabs "Anyfile:t(0,61)=s4_p_File_:(0,53),0,32;;",128,0,0,0 .stabs "Timestamp:t(0,62)=s104Datevalid:(0,38),0,1;Timevalid:(0,38),1,1;Year:(0,1), 2,32;Month:(0,63)=r(0,1);0000000000001;0000000000014;,34,4;Day:(0,64)=r(0,1) ;0000000000001;0000000000037;,38,5;Dayofweek:(0,65)=r(0,1);0000000000000;000 0000000006;,43,3;Hour:(0,66)=r(0,1);0000000000000;0000000000027;,46,5;Minute :(0,67)=r(0,1);0000000000000;0000000000073;,51,6;Second:(0,68)=r(0,1);000000 0000000;0000000000075;,57,6;Microsecond:(0,69)=r(0,1);0000000000000;00000036 41077;,63,20;Timezone:(0,1),83,32;Dst:(0,38),115,1;Tzname1:(0,70)=s44Capacit y:(0,2),0,32;length:(0,2),32,32;_p_Schema_:(0,71)=ar(0,1);1;33;(0,50),64,264 ;;,128,352;Tzname2:(0,72)=s44Capacity:(0,2),0,32;length:(0,2),32,32;_p_Schem a_:(0,73)=ar(0,1);1;33;(0,50),64,264;;,480,352;;",128,0,0,0 .stabs "Bindingtype:t(0,74)=s2124Bound:(0,38),0,1;Force:(0,38),1,1;Extensions_valid :(0,38),2,1;Readable:(0,38),3,1;Writable:(0,38),4,1;Executable:(0,38),5,1;Ex isting:(0,38),6,1;Directory:(0,38),7,1;Special:(0,38),8,1;Symlink:(0,38),9,1 ;Size:(0,17),10,64;Accesstime:(0,17),74,64;Modificationtime:(0,17),138,64;Ch angetime:(0,17),202,64;User:(0,1),266,32;Group:(0,1),298,32;Mode:(0,1),330,3 2;Device:(0,1),362,32;Inode:(0,1),394,32;Links:(0,1),426,32;Textbinary:(0,38 ),458,1;Handle:(0,1),459,32;Closeflag:(0,38),491,1;Name:(0,75)=s2060Capacity :(0,2),0,32;length:(0,2),32,32;_p_Schema_:(0,76)=ar(0,1);1;2049;(0,50),64,16 392;;,512,16480;;",128,0,0,0 .local S .common S,2,1 .section ".data" .type S2, #object .size S2, 2 S2: .asciz "\024" .section ".rodata" .LLC0: .asciz "\024" .LLC1: .ascii "\005" .align 8 .LLC2: .asciz "OK\n" .align 8 .LLC3: .asciz "failed\n" .section ".text" .align 4 .stabs "_p__M0_main_program:F(0,46)",36,0,7,_p__M0_main_program .global _p__M0_main_program .type _p__M0_main_program, #function .proc 020 _p__M0_main_program: .stabn 68,0,7,.LLM1-_p__M0_main_program .LLM1: !#PROLOGUE# 0 save %sp, -112, %sp !#PROLOGUE# 1 .stabn 68,0,9,.LLM2-_p__M0_main_program .LLM2: sethi %hi(.LLC0), %g1 or %g1, %lo(.LLC0), %o0 mov 1, %o1 mov 10, %o2 sethi %hi(S), %g1 or %g1, %lo(S), %o3 mov 1, %o4 mov 10, %o5 call _p_Set_Copy, 0 nop .stabn 68,0,11,.LLM3-_p__M0_main_program .LLM3: sethi %hi(.LLC1), %g1 or %g1, %lo(.LLC1), %o0 mov 3, %o1 mov 5, %o2 sethi %hi(S), %g1 or %g1, %lo(S), %o3 mov 1, %o4 mov 10, %o5 call _p_Set_Equal, 0 nop mov %o0, %g1 and %g1, 0xff, %g1 cmp %g1, 0 be .LL2 nop .stabn 68,0,11,.LLM4-_p__M0_main_program .LLM4: sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 mov 1568, %o1 call _p_Write_Init, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 sethi %hi(.LLC2), %g1 or %g1, %lo(.LLC2), %o1 mov 3, %o2 sethi %hi(-2147483648), %o3 call _p_Write_String, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 call _p_Write_Flush, 0 nop sethi %hi(_p_InOutRes), %g1 or %g1, %lo(_p_InOutRes), %g1 ld [%g1], %g1 cmp %g1, 0 be .LL5 nop call _p_CheckInOutRes, 0 nop .LL2: sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 mov 1568, %o1 call _p_Write_Init, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 sethi %hi(.LLC3), %g1 or %g1, %lo(.LLC3), %o1 mov 7, %o2 sethi %hi(-2147483648), %o3 call _p_Write_String, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 call _p_Write_Flush, 0 nop sethi %hi(_p_InOutRes), %g1 or %g1, %lo(_p_InOutRes), %g1 ld [%g1], %g1 cmp %g1, 0 be .LL5 nop call _p_CheckInOutRes, 0 nop .LL5: .stabn 68,0,12,.LLM5-_p__M0_main_program .LLM5: sethi %hi(S), %g1 or %g1, %lo(S), %o0 mov 1, %o1 mov 10, %o2 sethi %hi(S2), %g1 or %g1, %lo(S2), %o3 mov 1, %o4 mov 10, %o5 call _p_Set_Equal, 0 nop mov %o0, %g1 and %g1, 0xff, %g1 cmp %g1, 0 be .LL8 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 mov 1568, %o1 call _p_Write_Init, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 sethi %hi(.LLC2), %g1 or %g1, %lo(.LLC2), %o1 mov 3, %o2 sethi %hi(-2147483648), %o3 call _p_Write_String, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 call _p_Write_Flush, 0 nop sethi %hi(_p_InOutRes), %g1 or %g1, %lo(_p_InOutRes), %g1 ld [%g1], %g1 cmp %g1, 0 be .LL1 nop call _p_CheckInOutRes, 0 nop .LL8: sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 mov 1568, %o1 call _p_Write_Init, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 sethi %hi(.LLC3), %g1 or %g1, %lo(.LLC3), %o1 mov 7, %o2 sethi %hi(-2147483648), %o3 call _p_Write_String, 0 nop sethi %hi(_p_Output), %g1 or %g1, %lo(_p_Output), %g1 ld [%g1], %o0 call _p_Write_Flush, 0 nop sethi %hi(_p_InOutRes), %g1 or %g1, %lo(_p_InOutRes), %g1 ld [%g1], %g1 cmp %g1, 0 be .LL1 nop call _p_CheckInOutRes, 0 nop .LL1: nop ret restore .size _p__M0_main_program, .-_p__M0_main_program .LLscope0: .stabs "",36,0,0,.LLscope0-_p__M0_main_program .local static_ctor_run_condition_0_1 .common static_ctor_run_condition_0_1,1,1 .align 4 .stabs "<implicit code>",130,0,0,0 .stabs "_p__M0_init:F(0,46)",36,0,13,_p__M0_init .global _p__M0_init .type _p__M0_init, #function .proc 020 _p__M0_init: .stabs "<implicit code>",132,0,0,.LLtext1 .LLtext1: .stabn 68,0,13,.LLM6-_p__M0_init .LLM6: !#PROLOGUE# 0 save %sp, -112, %sp !#PROLOGUE# 1 sethi %hi(static_ctor_run_condition_0_1), %g1 or %g1, %lo(static_ctor_run_condition_0_1), %g1 ldub [%g1], %g1 and %g1, 0xff, %g1 cmp %g1, 0 bne .LL14 nop .stabn 68,0,13,.LLM7-_p__M0_init .LLM7: sethi %hi(static_ctor_run_condition_0_1), %g1 or %g1, %lo(static_ctor_run_condition_0_1), %o5 mov 1, %g1 stb %g1, [%o5] call _p_DoInitProc, 0 nop .LL14: nop ret restore .size _p__M0_init, .-_p__M0_init .LLscope1: .stabs "",36,0,0,.LLscope1-_p__M0_init .align 4 .stabs "main:F(1,1)=r(1,1);-2147483648;2147483647;",36,0,13,main .stabs "argc:p(1,1)",160,0,13,68 .stabs "argv:p(1,2)=*(0,49)",160,0,13,72 .stabs "envp:p(1,2)",160,0,13,76 .global main .type main, #function .proc 04 main: .stabn 68,0,13,.LLM8-main .LLM8: !#PROLOGUE# 0 save %sp, -112, %sp !#PROLOGUE# 1 st %i0, [%fp+68] st %i1, [%fp+72] st %i2, [%fp+76] sethi %hi(_p_GPC_RTS_VERSION_20050331), %g1 or %g1, %lo(_p_GPC_RTS_VERSION_20050331), %g1 ld [%g1], %g1 ld [%fp+68], %o0 ld [%fp+72], %o1 ld [%fp+76], %o2 mov 0, %o3 call _p_initialize, 0 nop call _p__M0_init, 0 nop call _p__M0_main_program, 0 nop call _p_finalize, 0 nop mov 0, %g1 mov %g1, %i0 ret restore .size main, .-main .LLscope2: .stabs "",36,0,0,.LLscope2-main .stabn 162,0,0,0 .stabs "S:S(0,77)=@s16;S(0,78)=r(0,1);0000000000001;0000000000012;",40,0,6,S .stabs "S2:S(0,79)=@s16;S(0,80)=r(0,1);0000000000001;0000000000012;",38,0,7,S2 .text .stabs "",100,0,0,.Letext .Letext: .ident "GCC: (GNU) 20050331, based on gcc-3.4.3"
However, the file I got from the cross compiler looks OK, so the most likely reason is assembler or linker.
Should I try GNU ones?
Regards
Pascal Viandier pascal@accovia.com
Pascal Viandier wrote:
That may be the difference. IIRC I used Gnu assembler and linker (and I have different versions of Sun tools).
If I remember well, the instructions to build gpc say to avoid GNU assembler and linker under Solaris. That's why I did not use them.
For some reason you gpc installation works differently then other, I just trying to find a possible cause.
The test program:
<snip> > > Program received signal SIGSEGV, Segmentation fault. > > $00029134 in _p_Set_Equal (Seta=$55d84, Lowa=0, Higha=1312, Setb=$41c62, > > Lowb=3, > > Highb=0) > > That shows paramteters at the point of crash (where they changed by the > execution). Can you put a breakpoint at _p_Set_Equal and check if > parameters > are correct: both Seta nad Setb should point to number 40.
A bit far from 40: (gdb) p *(long *) Seta $4 = 83886080 (gdb) p *(long *) Setb $3 = 1280
If the paramters are incorrect then one should egzamine assembly file obtained via `gpc -g -S adam3k2.pas'.
Here it is:
.local S .common S,2,1 .section ".data" .type S2, #object .size S2, 2
^^^ wrong size
S2: .asciz "\024"
^^^^^^ Looks unaligned
.section ".rodata" .LLC0: .asciz "\024" .LLC1: .ascii "\005" .align 8
.stabs "S:S(0,77)=@s16;S(0,78)=r(0,1);0000000000001;0000000000012;",40,0,6,S .stabs "S2:S(0,79)=@s16;S(0,80)=r(0,1);0000000000001;0000000000012;",38,0,7,S2
^^^ Again wrong size.
This output explains test failures and crashes: your gpc thinks that the sets above take 16 bits, but gpc runtime expects 32 bits. Cross compiler gives me the correct size.
ATM it is still not clear why your gpc uses wrong size for sets, but one possible explanation is quite simple: gcc contains code which allocates to each set a sequence of bytes. Gpc patches backend files to use a sequence of words for a file. So your output would be expected if some of backend files are used unpatched.
However, the file I got from the cross compiler looks OK, so the most likely reason is assembler or linker.
Should I try GNU ones?
It looks that your gpc was built incorrectly. With the new info there is no reason to specifically suspect assembler or linker.
I think that you should first re-build gpc from scratch: unpack the sources, configure and make. It may be wise to use 20051116 version as it already contains patches needed by Solaris.
If the problem persist after re-build one should the examine messages appearing during build. Normally messages go to screen and vanish, but there are many ways to capture them. For example, I typically write:
make bootstrap > mlogg 2>&1
I just tried the new gpc 20051116 based on gcc 3.4.4 and the gpc testsuite shows no more problems with sets. As you suggested, it was probably due to a bad build of my Solaris GPC 2050331.
Please consider this issue as closed.
Regards
Pascal Viandier pascal@accovia.com
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Waldek Hebisch Envoyé : December 8, 2005 23:56 À : gpc@gnu.de Objet : Re: RE : RE : Crash with sets under Solaris
Pascal Viandier wrote:
That may be the difference. IIRC I used Gnu assembler and linker (and I have different versions of Sun tools).
If I remember well, the instructions to build gpc say to avoid GNU
assembler
and linker under Solaris. That's why I did not use them.
For some reason you gpc installation works differently then other, I just trying to find a possible cause.
The test program:
<snip> > > Program received signal SIGSEGV, Segmentation fault. > > $00029134 in _p_Set_Equal (Seta=$55d84, Lowa=0, Higha=1312,
Setb=$41c62,
Lowb=3, Highb=0)
That shows paramteters at the point of crash (where they changed by
the
execution). Can you put a breakpoint at _p_Set_Equal and check if parameters are correct: both Seta nad Setb should point to number 40.
A bit far from 40: (gdb) p *(long *) Seta $4 = 83886080 (gdb) p *(long *) Setb $3 = 1280
If the paramters are incorrect then one should egzamine assembly file obtained via `gpc -g -S adam3k2.pas'.
Here it is:
.local S .common S,2,1 .section ".data" .type S2, #object .size S2, 2
^^^ wrong sizeS2: .asciz "\024"
^^^^^^ Looks unaligned.section ".rodata" .LLC0: .asciz "\024" .LLC1: .ascii "\005" .align 8
.stabs "S:S(0,77)=@s16;S(0,78)=r(0,1);0000000000001;0000000000012;",40,0,6,S .stabs "S2:S(0,79)=@s16;S(0,80)=r(0,1);0000000000001;0000000000012;",38,0,7,S2
^^^ Again wrong size.This output explains test failures and crashes: your gpc thinks that the sets above take 16 bits, but gpc runtime expects 32 bits. Cross compiler gives me the correct size.
ATM it is still not clear why your gpc uses wrong size for sets, but one possible explanation is quite simple: gcc contains code which allocates to each set a sequence of bytes. Gpc patches backend files to use a sequence of words for a file. So your output would be expected if some of backend files are used unpatched.
However, the file I got from the cross compiler looks OK, so the most likely reason is assembler or linker.
Should I try GNU ones?
It looks that your gpc was built incorrectly. With the new info there is no reason to specifically suspect assembler or linker.
I think that you should first re-build gpc from scratch: unpack the sources, configure and make. It may be wise to use 20051116 version as it already contains patches needed by Solaris.
If the problem persist after re-build one should the examine messages appearing during build. Normally messages go to screen and vanish, but there are many ways to capture them. For example, I typically write:
make bootstrap > mlogg 2>&1
-- Waldek Hebisch hebisch@math.uni.wroc.pl
-
Pascal Viandier -
Waldek Hebisch