Sorry about this horrid use of gotos in the following nasty bit of code but it core dumps on Solaris 2.6 - it's easy to workaround in the following snippet but not so easy (actually just very laborious) in the original inherited code.
'bye for now, John
For info:-
gpc -v
returns:-
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release)
(* sample program *)
program bug1 (Output);
procedure level_1 ;
procedure level_2 ; label 2;
procedure level_3 ; begin (* level_3 code *) writeln( 'level_3' ) ; writeln( 'goto 2' ) ; goto 2 ; writeln( 'should not get here' ) ; end ; (* level_3 code *)
begin (* level_2 code *) writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here' ) ; return ;
2:
writeln( 'label 2' ) ; end ; (* level_2 code *)
begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ; end ; (* level_1 code *)
begin level_1 ; end.
On 10 Nov 2001, at 1:45, John P.R. Archer wrote:
Sorry about this horrid use of gotos in the following nasty bit of code but it core dumps on Solaris 2.6...
As a point of reference, with:
Reading specs from E:\Programming\Pascal\i486-pc-mingw32msvc\2.95.3\specs gpc version 20010924, based on 2.95.3 20010315 (release)
I get:
level_1 level_2 level_3 goto 2 label 2 should not get here
Also:
[...]
begin (* level_2 code *) writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here' ) ; return ;
2:
writeln( 'label 2' ) ;end ; (* level_2 code *)
begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ; end ; (* level_1 code *)
...I cannot see why the level 1 "should not get here" should not be executed.
-- Dave
"J. David Bryan" wrote:
On 10 Nov 2001, at 1:45, John P.R. Archer wrote:
Sorry about this horrid use of gotos in the following nasty bit of code but it core dumps on Solaris 2.6...
As a point of reference, with:
Reading specs from E:\Programming\Pascal\i486-pc-mingw32msvc\2.95.3\specs gpc version 20010924, based on 2.95.3 20010315 (release)
I get:
level_1 level_2 level_3 goto 2 label 2 should not get here
ooops, so do I using Sparc Pascal on Solaris 2.6, see below.
Also:
[...]
begin (* level_2 code *) writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here' ) ; return ;
2:
writeln( 'label 2' ) ;end ; (* level_2 code *)
begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ; end ; (* level_1 code *)
...I cannot see why the level 1 "should not get here" should not be executed.
indeed - the bug was reported to me and I passed it on, I should have compiled & executed the source using Sparc Pascal before submission. Sorry.
-- Dave
John
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de]On Behalf Of J. David Bryan Sent: 10 November 2001 04:35 To: GNU Pascal List Subject: Re: Bug Report: goto bug
On 10 Nov 2001, at 1:45, John P.R. Archer wrote:
Sorry about this horrid use of gotos in the following nasty bit
of code but
it core dumps on Solaris 2.6...
As a point of reference, with:
Reading specs from E:\Programming\Pascal\i486-pc-mingw32msvc\2.95.3\specs gpc version 20010924, based on 2.95.3 20010315 (release)
I get:
level_1 level_2 level_3 goto 2 label 2 should not get here
Also:
[...]
begin (* level_2 code *) writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here' ) ; return ;
2:
writeln( 'label 2' ) ;end ; (* level_2 code *)
begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ; end ; (* level_1 code *)
...I cannot see why the level 1 "should not get here" should not be executed.
My fault I'm afraid. I wasn't on the list before, so John Archer submitted this for me. I did a slight change to my original bug source and, since it core dumped, I didn't spot the unhelpful writeln. The original source was:-
program bug1 (output);
procedure level_1 ; label 1;
procedure level_2 ;
procedure level_3 ; begin (* level_3 code *) writeln( 'level_3' ) ; writeln( 'goto 1' ) ; goto 1 ; writeln( 'should not get here1' ) ; end ; (* level_3 code *)
begin (* level_2 code *) writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here2' ) ; end ; (* level_2 code *)
begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ;
1:
writeln( 'label 1' ) ; end ; (* level_1 code *)
begin level_1 ; end.
Following John's suggestion I used Sparc Pascal and the run gives:-
level_1 level_2 level_3 goto 1 label 1
but with GPC I compile using just:-
gpc bug1.pas
and the run gives:-
level_1 level_2 level_3 goto 1 Segmentation Fault(coredump)
I tried to find more with GDB but the output isn't much use:-
gdb a.out core GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.6"... Core was generated by `a.out'. Program terminated with signal 11, Segmentation Fault. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1...done. #0 0x178d8 in Level_3.5 () (gdb) where #0 0x178d8 in Level_3.5 () Cannot access memory at address 0xbf1.
It rather looks like the stack manipulation (or something) has got rather mucked up.
Just as a reminder:-
gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release)
Cheers, Martin.
Martin G C Davies wrote:
My fault I'm afraid. I wasn't on the list before, so John Archer submitted this for me. I did a slight change to my original bug source and, since it core dumped, I didn't spot the unhelpful writeln. The original source was:-
program bug1 (output);
procedure level_1 ; label 1;
procedure level_2 ; procedure level_3 ;begin (* level_3 code *) writeln( 'level_3' ) ; writeln( 'goto 1' ) ; goto 1 ; writeln( 'should not get here1' ) ; end ; (* level_3 code *)
begin (* level_2 code *)writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here2' ) ; end ; (* level_2 code *)
begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ;
1:
writeln( 'label 1' ) ;end ; (* level_1 code *)
begin level_1 ; end.
but with GPC I compile using just:-
gpc bug1.pas
and the run gives:-
level_1 level_2 level_3 goto 1 Segmentation Fault(coredump)
I tried to find more with GDB but the output isn't much use:-
It rather looks like the stack manipulation (or something) has got rather mucked up.
Doesn't crash for me (neither on Linux nor Solaris). Maybe this bug has been fixed with some other recent fix. So I have to ask you to do more debugging on your machine or wait for the next GPC release and retry with it ...
Frank
On 10 Nov 2001, at 11:03, Martin G C Davies wrote:
The original source was:-
[...]
but with GPC [...] the run gives:-
level_1 level_2 level_3 goto 1 Segmentation Fault(coredump)
Using:
Reading specs from E:\Programming\Pascal\i486-pc-mingw32msvc\2.95.3\specs gpc version 20010924, based on 2.95.3 20010315 (release)
I get:
level_1 level_2 level_3 goto 1 label 1
It rather looks like the stack manipulation (or something) has got rather mucked up.
I note from the generated code on the x86 processor that the jump is indirect through a location on the stack. Does the Sparc object to this? I seem to recall that certain processors don't allow jumps to code on the stack; might that possibly extend to jumps through the stack as well?
Or perhaps it's simply a GPC code generation bug, although one that doesn't occur equivalently on the x86.
-- Dave
J. David Bryan wrote:
I note from the generated code on the x86 processor that the jump is indirect through a location on the stack. Does the Sparc object to this? I seem to recall that certain processors don't allow jumps to code on the stack; might that possibly extend to jumps through the stack as well?
This seems strange at first (*), but would explain why it doesn't crash for me on Solaris. If so, then noexec_user_stack must have been set on your system, and unsetting it will avoid the crash. Can you try this?
(*) Quite strange, actually, since then any parameters and local variables of procedural type would not work.
Frank
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de]On Behalf Of Frank Heckenbach Sent: 11 November 2001 07:58 To: gpc@gnu.de Subject: Re: Bug Report: goto bug
J. David Bryan wrote:
I note from the generated code on the x86 processor that the jump is indirect through a location on the stack. Does the Sparc
object to this?
I seem to recall that certain processors don't allow jumps to
code on the
stack; might that possibly extend to jumps through the stack as well?
This seems strange at first (*), but would explain why it doesn't crash for me on Solaris. If so, then noexec_user_stack must have been set on your system, and unsetting it will avoid the crash. Can you try this?
(*) Quite strange, actually, since then any parameters and local variables of procedural type would not work.
It is not set (althought my Ultra is a machine where it could be - it's a sun4u). I have attached my /etc/system so you can see it isn't set. What's more I compiled and ran the program below (from the GPC Pascal Manual) that demonstrates procedure parameters working (from what I understood from (*)).
In case it's of use to someone I have attached the assembler (gpc -S) and it appears to be on the assembler "restore" that the SIGSEV occurs. If there is more info I can provide just let me know (and probably tell me how).
Cheers, Martin.
program LocalProceduralParameterDemo;
procedure CallProcedure (procedure Proc); begin Proc end;
procedure MainProcedure; var LocalVariable : Integer;
procedure LocalProcedure; begin WriteLn (LocalVariable) end;
begin LocalVariable := 42; CallProcedure (LocalProcedure) end;
begin MainProcedure end.
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
Hi,
I now have some more info on this bug in 20010924, and that is that it seems to have been introduced since 19990118. So compiling with version:-
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 19990118, based on gcc-2.8.1
the program runs:-
level_1 level_2 level_3 goto 1 label 1
but compiling with version:-
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release)
the program runs:-
level_1 level_2 level_3 goto 1 Segmentation Fault(coredump)
I captured the assembler from both version (with -S), performed an "sdiff -W" and the output is attached (as is the source).
Sadly I cannot use 19990118 for my "real" source because there are just too many things it cannot cope with so I really hope someone can give me a fix for the latest version.
Thanks for the help so far and fingers crossed you can help more.
Cheers, Martin.
Martin G C Davies wrote:
It is not set (althought my Ultra is a machine where it could be - it's a sun4u). I have attached my /etc/system so you can see it isn't set. What's more I compiled and ran the program below (from the GPC Pascal Manual) that demonstrates procedure parameters working (from what I understood from (*)).
So this doesn't seem to be the issue.
In case it's of use to someone I have attached the assembler (gpc -S) and it appears to be on the assembler "restore" that the SIGSEV occurs. If there is more info I can provide just let me know (and probably tell me how).
I now have some more info on this bug in 20010924, and that is that it seems to have been introduced since 19990118. So compiling with version:-
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 19990118, based on gcc-2.8.1
the program runs:-
level_1 level_2 level_3 goto 1 label 1
but compiling with version:-
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release)
This *might* also be a difference between the backend versions. If you can, please try to build GPC 20010924 with gcc-2.8.1 to see if that works (that's what I'm using, so it would explain why it works for me).
the program runs:-
level_1 level_2 level_3 goto 1 Segmentation Fault(coredump)
I captured the assembler from both version (with -S), performed an "sdiff -W" and the output is attached (as is the source).
I'm not used to reading this format. I'd prefer a unidiff (or the other assembler file, so I can make a diff myself).
Frank
Frank,
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs
gpc version 20010924, based on 2.95.3 20010315 (release)
This *might* also be a difference between the backend versions. If you can, please try to build GPC 20010924 with gcc-2.8.1 to see if that works (that's what I'm using, so it would explain why it works for me).
Thanks for that suggestion (and the subsequent private email help about the build). Indeed this has fixed the problem for me - so it appears to be a GCC problem as opposed to GPC.
Thus, I can now continue with my new:-
gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 20010924, based on gcc-2.8.1
Is there anything I should do to notify anyone about the GCC problem or should it get picked up from this mailing list anyway?
Cheers, Martin.
Martin G C Davies wrote:
Thanks for that suggestion (and the subsequent private email help about the build). Indeed this has fixed the problem for me - so it appears to be a GCC problem as opposed to GPC.
Thus, I can now continue with my new:-
gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 20010924, based on gcc-2.8.1
Is there anything I should do to notify anyone about the GCC problem or should it get picked up from this mailing list anyway?
Not yet. I'll first try to find out if it's really a GCC bug or just something in the interface between GPC and GCC which broke with the new version. I have access to Solaris systems where I can try to reproduce the problem with a 2.95.x based GPC.
Frank
I wrote:
Martin G C Davies wrote:
Thanks for that suggestion (and the subsequent private email help about the build). Indeed this has fixed the problem for me - so it appears to be a GCC problem as opposed to GPC.
Thus, I can now continue with my new:-
gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 20010924, based on gcc-2.8.1
Is there anything I should do to notify anyone about the GCC problem or should it get picked up from this mailing list anyway?
Not yet. I'll first try to find out if it's really a GCC bug or just something in the interface between GPC and GCC which broke with the new version. I have access to Solaris systems where I can try to reproduce the problem with a 2.95.x based GPC.
OK, I can reproduce it, and it is a GCC bug. The following C program (using GCC extensions for nested functions and label declarations) is a direct translation from the Pascal program and it has the same problem (also only with 2.95.x on Solaris).
If you have access to a GCC 3.0 on Solaris, you might test it with that version.
So I think it's time to report it to the GCC maintainers. Will you do that (see the GCC documentaion for how and where), or should I?
extern int puts (const char *);
int main() { __label__ l1;
void foo() {
void bar() { puts ("goto l1"); goto l1; }
bar (); }
foo (); abort (); l1: puts ("label l1"); return 0; }
Frank
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de]On Behalf Of Frank Heckenbach Sent: 17 November 2001 09:22 To: gpc@gnu.de Subject: Re: Bug Report: goto bug
OK, I can reproduce it, and it is a GCC bug. The following C program (using GCC extensions for nested functions and label declarations)
It didn't occur to me to see if gcc had extensions to support this.
is a direct translation from the Pascal program and it has the same problem (also only with 2.95.x on Solaris).
If you have access to a GCC 3.0 on Solaris, you might test it with that version.
Seems to be ok on 3.0.1. Looks like I was a bit unlucky with the version I went for - I just assumed the latest gcc that gpc could build with would be best.
So I think it's time to report it to the GCC maintainers. Will you do that (see the GCC documentaion for how and where), or should I?
I would be very happy for you to report it.
extern int puts (const char *);
int main() { __label__ l1;
void foo() {
void bar() { puts ("goto l1"); goto l1; } bar ();}
foo (); abort (); l1: puts ("label l1"); return 0; }
Thanks once again for all your help.
Cheers, Martin.
Martin G C Davies wrote:
Seems to be ok on 3.0.1. Looks like I was a bit unlucky with the version I went for - I just assumed the latest gcc that gpc could build with would be best.
Well, some bugs are fixed, other bugs are new. The old story ...
So I think it's time to report it to the GCC maintainers. Will you do that (see the GCC documentaion for how and where), or should I?
I would be very happy for you to report it.
If it's ok in 3.0, I don't think they'd care much for a report. So we should just avoid 2.95 on Solaris.
Frank
-
Frank Heckenbach -
J. David Bryan -
John P.R. Archer -
Martin G C Davies