sigsegv in bison 32bit / works in 64bit.

[gary artim]

Hi --

I'm new to the list and bison. I'm running bison (linked from yacc) on
Fedora. I've been trying to figure out why my code segfaults on 32 bit
machines. I've tried this on linux versions of gentoo, fedora and in
both cases the code segs on the 32 bit machine and runs on the 64 bit.
I realize that it could be an alignment issue. I've instrumented my
code to see the runtime stack and they look the same. I'm hoping
someone has stumbled across this before? I was following the Pike book
" the Unix Programming Environment". My code is generated from tux.y
(attached) and some gdb output is listed below. Any help in how to
debug this would be great. I think what is happening is that the tux.y
uses a STOP instruction to signal an end to running. the STOP is
defined: #define STOP (Inst) 0. And line 30 of pop has a stack pointer
set to this which causes a read of memory loc 0 (a no no), but why
would this behave different on 64bit machines? Any help would be great
and appreciated much!


thanks,

-- Gary

This GDB was configured as "i586-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) r
Starting program: /home/gartim/4_64/tux4
a=1

Program received signal SIGSEGV, Segmentation fault.
0x005eee43 in memmove () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.10.1-5.i686
(gdb) bt
#0  0x005eee43 in memmove () from /lib/libc.so.6
#1  0x08049482 in pop () at code.c:30
#2  0x080494f5 in execute (p=0x804c3a0) at code.c:51
#3  0x08048a20 in main (argc=1, argv=0xbffff5b4) at tux.y:67
(gdb) list code.c:30
25      {
26              if (stackp <= stack)
27                      execerror("stack underflow", (char *) 0);
28              *stackp--;
29              //printf("[[%x]]\n", *stackp);
30              return *stackp;
31      }

tux.y
Description: Binary data