Hey guys,
I've got pike failing to build a deb on a sparc64 machine. It segfaults while trying to run precompile.sh using tpike. Is it really necessary to run precompile.sh on exported sources? If not - how can avoid it? And the most important issues:
- the original build failure record: http://buildd.debian.org/fetch.php?&pkg=pike7.4&ver=7.4.13-2&arc...
- a fragment of a failed build when just running 'make' in a debian-patched directory on sparc64
cpu : TI UltraSparc II (BlackBird) fpu : UltraSparc II integrated FPU promlib : Version 3 Revision 27 prom : 3.27.0 type : sun4u ncpus probed : 1 ncpus active : 1 Cpu0Bogo : 591.46 Cpu0ClkTck : 0000000011a4695a MMU Type : Spitfire
the fragment:
precompile: /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/master.pike /scratch/grendel/pike7.4-7.4.13/bin/mktreeopt.pike /scratch/grendel/pike7.4-7.4.13/src/treeopt.in (method=QQ) /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/precompile.sh: line 203: 15768 Segmentation fault $RUNPIKE $SCRIPT "$@" 1>&5
- a final fragment of strace from the above segfault:
22764 mprotect(0x2693c0, 52, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2693c0, 48, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x296da8, 1144, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2432, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2424, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 3376, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 brk(0) = 0x2ba000 22764 brk(0x2bc000) = 0x2bc000 22764 mprotect(0x2b70a8, 10104, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 --- SIGSEGV (Segmentation fault) --- 22764 +++ killed by SIGSEGV +++
- and a compile-time warning (not sure if related):
/scratch/grendel/pike7.4-7.4.13/src/program.c: In function store_constant': /scratch/grendel/pike7.4-7.4.13/src/program.c:4508: warning: variable e'might be clobbered by longjmp' or vfork'
Right now I'm trying to compile the deb on another sparc machine (will take a while), but I'd appreciate any help on that issue...
TIA,
marek
p.s. if you need access to one of the sparc machines, contact me privately, I think we will be able to arrange something.
Grendel,
I have such problems. Do you use --without-shared-nodes switche ? If so just remove it... :p I had that problem in Pike under FreeBSD x86 and alpha...
/Xavier
Hey guys,
I've got pike failing to build a deb on a sparc64 machine. It segfaults while trying to run precompile.sh using tpike. Is it really necessary to run precompile.sh on exported sources? If not - how can avoid it? And the most important issues:
- the original build failure record:
http://buildd.debian.org/fetch.php?&pkg=pike7.4&ver=7.4.13- 2&arch=sparc&stamp=1044077176&file=log&as=raw
- a fragment of a failed build when just running 'make' in a
debian-patched directory on sparc64
cpu : TI UltraSparc II (BlackBird) fpu : UltraSparc II integrated FPU promlib : Version 3 Revision 27 prom : 3.27.0 type : sun4u ncpus probed : 1 ncpus active : 1 Cpu0Bogo : 591.46 Cpu0ClkTck : 0000000011a4695a MMU Type : Spitfire
the fragment:
precompile: /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/ master.pike /scratch/grendel/pike7.4-7.4.13/bin/mktreeopt.pike /scratch/grendel/pike7.4-7.4.13/src/treeopt.in (method=QQ) /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/ precompile.sh: line 203: 15768 Segmentation fault $RUNPIKE $SCRIPT "$@" 1>&5
- a final fragment of strace from the above segfault:
22764 mprotect(0x2693c0, 52, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2693c0, 48, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x296da8, 1144, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2432, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2424, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 3376, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 brk(0) = 0x2ba000 22764 brk(0x2bc000) = 0x2bc000 22764 mprotect(0x2b70a8, 10104, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 --- SIGSEGV (Segmentation fault) --- 22764 +++ killed by SIGSEGV +++
- and a compile-time warning (not sure if related):
/scratch/grendel/pike7.4-7.4.13/src/program.c: In function store_constant': /scratch/grendel/pike7.4-7.4.13/src/program.c:4508: warning: variable e'might be clobbered by longjmp' or vfork'
Right now I'm trying to compile the deb on another sparc machine (will take a while), but I'd appreciate any help on that issue...
TIA,
marek
p.s. if you need access to one of the sparc machines, contact me privately, I think we will be able to arrange something.
<mime-attachment>
On Mon, Feb 03, 2003 at 01:40:47AM +0100, Xavier Beaudouin scribbled:
Grendel,
I have such problems. Do you use --without-shared-nodes switche ? If so just remove it... :p I had that problem in Pike under FreeBSD x86 and alpha...
Nope... I'm not using that switch. See in packaging/debian/rules/ - that's the switches I use.
marek
What does gdb say?
/ Henrik Grubbström (Lysator)
Previous text:
2003-02-01 22:46: Subject: Pike 7.4 on Debian/Sparc - a build problem
Hey guys,
I've got pike failing to build a deb on a sparc64 machine. It segfaults while trying to run precompile.sh using tpike. Is it really necessary to run precompile.sh on exported sources? If not - how can avoid it? And the most important issues:
- the original build failure record:
http://buildd.debian.org/fetch.php?&pkg=pike7.4&ver=7.4.13-2&arc...
- a fragment of a failed build when just running 'make' in a debian-patched
directory on sparc64
cpu : TI UltraSparc II (BlackBird) fpu : UltraSparc II integrated FPU promlib : Version 3 Revision 27 prom : 3.27.0 type : sun4u ncpus probed : 1 ncpus active : 1 Cpu0Bogo : 591.46 Cpu0ClkTck : 0000000011a4695a MMU Type : Spitfire
the fragment:
precompile: /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/master.pike /scratch/grendel/pike7.4-7.4.13/bin/mktreeopt.pike /scratch/grendel/pike7.4-7.4.13/src/treeopt.in (method=QQ) /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/precompile.sh: line 203: 15768 Segmentation fault $RUNPIKE $SCRIPT "$@" 1>&5
- a final fragment of strace from the above segfault:
22764 mprotect(0x2693c0, 52, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2693c0, 48, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x296da8, 1144, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2432, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2424, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 3376, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 brk(0) = 0x2ba000 22764 brk(0x2bc000) = 0x2bc000 22764 mprotect(0x2b70a8, 10104, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 --- SIGSEGV (Segmentation fault) --- 22764 +++ killed by SIGSEGV +++
- and a compile-time warning (not sure if related):
/scratch/grendel/pike7.4-7.4.13/src/program.c: In function store_constant': /scratch/grendel/pike7.4-7.4.13/src/program.c:4508: warning: variable e'might be clobbered by longjmp' or vfork'
Right now I'm trying to compile the deb on another sparc machine (will take a while), but I'd appreciate any help on that issue...
TIA,
marek
p.s. if you need access to one of the sparc machines, contact me privately, I think we will be able to arrange something.
/ Brevbäraren
On Mon, Feb 03, 2003 at 01:45:02PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
What does gdb say?
Ok, here it goes (the compiler is gcc 3.2):
(gdb) r Starting program: /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/master.pike [New Thread 16384 (LWP 29510)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 29510)] 0x0037dab0 in sparc_flush_instruction_cache () (gdb) bt #0 0x0037dab0 in sparc_flush_instruction_cache () #1 0x001ea980 in make_program_executable (p=0x4af9c8) at /scratch/grendel/pike7.4-7.4.13/src/program.c:7084 #2 0x0025c7a0 in eval_low (n=0x4dd8e8, print_error=1) at /scratch/grendel/pike7.4-7.4.13/src/las.c:5348 #3 0x000fecd8 in do_docode2 (n=0x4dd948, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1762 #4 0x000f5df8 in do_docode (n=0x4dd948, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #5 0x000fc230 in do_docode2 (n=0x4dd978, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1377 #6 0x000f5df8 in do_docode (n=0x4dd978, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #7 0x000fdaa0 in do_docode2 (n=0x4dd9a8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1582 #8 0x000f5df8 in do_docode (n=0x4de428, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #9 0x000fe06c in do_docode2 (n=0x4de458, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1654 #10 0x000f5df8 in do_docode (n=0x4de458, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #11 0x000fc230 in do_docode2 (n=0x4de3f8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1377 #12 0x000f5df8 in do_docode (n=0x4de3f8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #13 0x000fdaa0 in do_docode2 (n=0x4de3c8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1582 #14 0x000f5df8 in do_docode (n=0x4de338, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #15 0x001019d4 in do_code_block (n=0x4de338) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:2254 #16 0x0025f4c4 in dooptcode (name=0x4d5f74, n=0x4de338, type=0x4d7c60, modifiers=1) at /scratch/grendel/pike7.4-7.4.13/src/las.c:5689 #17 0x0002d00c in yyparse () at /tmp/pikedeb.d9df18af4c/7.4/src/language.yacc:886 #18 0x001e1e30 in run_pass2 (c=0x4b29e8) at /scratch/grendel/pike7.4-7.4.13/src/program.c:5653 #19 0x001e3a9c in compile (aprog=0x4ebe90, ahandler=0x0, amajor=-1, aminor=-1, atarget=0x0, aplaceholder=0x0) at /scratch/grendel/pike7.4-7.4.13/src/program.c:5870 #20 0x0027b458 in f_compile (args=1) at /scratch/grendel/pike7.4-7.4.13/src/builtin_functions.c:3225 #21 0x00172e34 in get_master () at /scratch/grendel/pike7.4-7.4.13/src/object.c:540 #22 0x001582bc in main (argc=4, argv=0xeffffd34) at /scratch/grendel/pike7.4-7.4.13/src/main.c:703 #23 0x701c4900 in __libc_start_main () from /lib/libc.so.6
(sorry for the long lines, but that way the output is more readable)
TIA,
marek
On Mon, Feb 03, 2003 at 02:37:15PM +0100, Marek Habersack scribbled:
On Mon, Feb 03, 2003 at 01:45:02PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
What does gdb say?
Ok, here it goes (the compiler is gcc 3.2):
Sorry for the followup to my own post, but configuring pike with --without-machine-code worked fine with a strange exception - the first time precompile.sh was ran it failed to find tpike, the 2nd run found tpike and everything seems to have worked fine.
marek
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 29510)] 0x0037dab0 in sparc_flush_instruction_cache () (gdb) bt #0 0x0037dab0 in sparc_flush_instruction_cache ()
Ok, looks like it doesn't like the inlined machine code of sparc_flush_instruction_cache().
What does a disassembly of sparc_flush_instruction_cache() give?
What does info reg say?
Try compiling without machine-code.
/ Henrik Grubbström (Lysator)
Previous text:
2003-02-03 14:37: Subject: Re: Pike 7.4 on Debian/Sparc - a build problem
On Mon, Feb 03, 2003 at 01:45:02PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
What does gdb say?
Ok, here it goes (the compiler is gcc 3.2):
(gdb) r Starting program: /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/master.pike [New Thread 16384 (LWP 29510)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 29510)] 0x0037dab0 in sparc_flush_instruction_cache () (gdb) bt #0 0x0037dab0 in sparc_flush_instruction_cache () #1 0x001ea980 in make_program_executable (p=0x4af9c8) at /scratch/grendel/pike7.4-7.4.13/src/program.c:7084 #2 0x0025c7a0 in eval_low (n=0x4dd8e8, print_error=1) at /scratch/grendel/pike7.4-7.4.13/src/las.c:5348 #3 0x000fecd8 in do_docode2 (n=0x4dd948, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1762 #4 0x000f5df8 in do_docode (n=0x4dd948, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #5 0x000fc230 in do_docode2 (n=0x4dd978, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1377 #6 0x000f5df8 in do_docode (n=0x4dd978, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #7 0x000fdaa0 in do_docode2 (n=0x4dd9a8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1582 #8 0x000f5df8 in do_docode (n=0x4de428, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #9 0x000fe06c in do_docode2 (n=0x4de458, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1654 #10 0x000f5df8 in do_docode (n=0x4de458, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #11 0x000fc230 in do_docode2 (n=0x4de3f8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1377 #12 0x000f5df8 in do_docode (n=0x4de3f8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #13 0x000fdaa0 in do_docode2 (n=0x4de3c8, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:1582 #14 0x000f5df8 in do_docode (n=0x4de338, flags=6) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:297 #15 0x001019d4 in do_code_block (n=0x4de338) at /scratch/grendel/pike7.4-7.4.13/src/docode.c:2254 #16 0x0025f4c4 in dooptcode (name=0x4d5f74, n=0x4de338, type=0x4d7c60, modifiers=1) at /scratch/grendel/pike7.4-7.4.13/src/las.c:5689 #17 0x0002d00c in yyparse () at /tmp/pikedeb.d9df18af4c/7.4/src/language.yacc:886 #18 0x001e1e30 in run_pass2 (c=0x4b29e8) at /scratch/grendel/pike7.4-7.4.13/src/program.c:5653 #19 0x001e3a9c in compile (aprog=0x4ebe90, ahandler=0x0, amajor=-1, aminor=-1, atarget=0x0, aplaceholder=0x0) at /scratch/grendel/pike7.4-7.4.13/src/program.c:5870 #20 0x0027b458 in f_compile (args=1) at /scratch/grendel/pike7.4-7.4.13/src/builtin_functions.c:3225 #21 0x00172e34 in get_master () at /scratch/grendel/pike7.4-7.4.13/src/object.c:540 #22 0x001582bc in main (argc=4, argv=0xeffffd34) at /scratch/grendel/pike7.4-7.4.13/src/main.c:703 #23 0x701c4900 in __libc_start_main () from /lib/libc.so.6
(sorry for the long lines, but that way the output is more readable)
TIA,
marek
/ Brevbäraren
On Mon, Feb 03, 2003 at 03:25:02PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 29510)] 0x0037dab0 in sparc_flush_instruction_cache () (gdb) bt #0 0x0037dab0 in sparc_flush_instruction_cache ()
Ok, looks like it doesn't like the inlined machine code of sparc_flush_instruction_cache().
What does a disassembly of sparc_flush_instruction_cache() give?
0x37daac <sparc_flush_instruction_cache>: cmp %o1, 1 0x37dab0 <sparc_flush_instruction_cache+4>: flush %o0 + %o1 0x37dab4 <sparc_flush_instruction_cache+8>: bge,a 0x37dab0 <sparc_flush_instruction_cache+4> 0x37dab8 <sparc_flush_instruction_cache+12>: subcc %o1, 8, %o1 0x37dabc <sparc_flush_instruction_cache+16>: retl
What does info reg say?
g0 0x0 0 g1 0xf3000 995328 g2 0x1009 4105 g3 0x0 0 g4 0x24c81c 2410524 g5 0x55555555 1431655765 g6 0x70128080 1880260736 g7 0x0 0 o0 0x5045f8 5260792 o1 0x9de0 40416 o2 0x4af9c8 4913608 o3 0x0 0 o4 0x0 0 o5 0x1267 4711 sp 0xefffe0e8 4026523880 o7 0x1ea978 2009464 l0 0x3a9700 3839744 l1 0x1 1 l2 0x0 0 l3 0x0 0 l4 0x80000000 -2147483648 l5 0x0 0 l6 0x0 0 l7 0x0 0 i0 0x4af9c8 4913608 i1 0x3a4588 3818888 i2 0x0 0 i3 0x0 0 i4 0x0 0 i5 0x938 2360 fp 0xefffe150 4026523984 i7 0x25c798 2475928 y 0x7b7a88a 129476746 psr 0xff000082 -16777086 icc:----, pil:0, s:1, ps:0, et:0, cwp:2 wim 0x0 0 tbr 0x0 0 pc 0x37dab0 3660464 npc 0x37dab4 3660468 fpsr 0x0 0 rd:N, tem:0, ns:0, ver:0, ftt:0, qne:0, fcc:=, aexc:0, cexc:0 cpsr 0x0 0
Try compiling without machine-code.
that works fine.
thanks,
marek
#0 0x0037dab0 in sparc_flush_instruction_cache ()
What does a disassembly of sparc_flush_instruction_cache() give?
0x37daac <sparc_flush_instruction_cache>: cmp %o1, 1 0x37dab0 <sparc_flush_instruction_cache+4>: flush %o0 + %o1
Ok, as I suspected, it seems to be the flush instruction that fails.
What does info reg say?
o0 0x5045f8 5260792 o1 0x9de0 40416
%o1 seems rather large.
/ Henrik Grubbström (Lysator)
Previous text:
2003-02-03 16:16: Subject: Re: Pike 7.4 on Debian/Sparc - a build problem
On Mon, Feb 03, 2003 at 03:25:02PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 29510)] 0x0037dab0 in sparc_flush_instruction_cache () (gdb) bt #0 0x0037dab0 in sparc_flush_instruction_cache ()
Ok, looks like it doesn't like the inlined machine code of sparc_flush_instruction_cache().
What does a disassembly of sparc_flush_instruction_cache() give?
0x37daac <sparc_flush_instruction_cache>: cmp %o1, 1 0x37dab0 <sparc_flush_instruction_cache+4>: flush %o0 + %o1 0x37dab4 <sparc_flush_instruction_cache+8>: bge,a 0x37dab0 <sparc_flush_instruction_cache+4> 0x37dab8 <sparc_flush_instruction_cache+12>: subcc %o1, 8, %o1 0x37dabc <sparc_flush_instruction_cache+16>: retl
What does info reg say?
g0 0x0 0 g1 0xf3000 995328 g2 0x1009 4105 g3 0x0 0 g4 0x24c81c 2410524 g5 0x55555555 1431655765 g6 0x70128080 1880260736 g7 0x0 0 o0 0x5045f8 5260792 o1 0x9de0 40416 o2 0x4af9c8 4913608 o3 0x0 0 o4 0x0 0 o5 0x1267 4711 sp 0xefffe0e8 4026523880 o7 0x1ea978 2009464 l0 0x3a9700 3839744 l1 0x1 1 l2 0x0 0 l3 0x0 0 l4 0x80000000 -2147483648 l5 0x0 0 l6 0x0 0 l7 0x0 0 i0 0x4af9c8 4913608 i1 0x3a4588 3818888 i2 0x0 0 i3 0x0 0 i4 0x0 0 i5 0x938 2360 fp 0xefffe150 4026523984 i7 0x25c798 2475928 y 0x7b7a88a 129476746 psr 0xff000082 -16777086 icc:----, pil:0, s:1, ps:0, et:0, cwp:2 wim 0x0 0 tbr 0x0 0 pc 0x37dab0 3660464 npc 0x37dab4 3660468 fpsr 0x0 0 rd:N, tem:0, ns:0, ver:0, ftt:0, qne:0, fcc:=, aexc:0, cexc:0 cpsr 0x0 0
Try compiling without machine-code.
that works fine.
thanks,
marek
/ Brevbäraren
On Mon, Feb 03, 2003 at 04:25:04PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
#0 0x0037dab0 in sparc_flush_instruction_cache ()
What does a disassembly of sparc_flush_instruction_cache() give?
0x37daac <sparc_flush_instruction_cache>: cmp %o1, 1 0x37dab0 <sparc_flush_instruction_cache+4>: flush %o0 + %o1
Ok, as I suspected, it seems to be the flush instruction that fails.
What does info reg say?
o0 0x5045f8 5260792 o1 0x9de0 40416
%o1 seems rather large.
indeed. What else can I do to help diagnose the problem?
marek
Try compiling --with-debug, and starting pike/tpike with -a7 or more.
/ Henrik Grubbström (Lysator)
Previous text:
2003-02-03 16:34: Subject: Re: Pike 7.4 on Debian/Sparc - a build problem
On Mon, Feb 03, 2003 at 04:25:04PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
#0 0x0037dab0 in sparc_flush_instruction_cache ()
What does a disassembly of sparc_flush_instruction_cache() give?
0x37daac <sparc_flush_instruction_cache>: cmp %o1, 1 0x37dab0 <sparc_flush_instruction_cache+4>: flush %o0 + %o1
Ok, as I suspected, it seems to be the flush instruction that fails.
What does info reg say?
o0 0x5045f8 5260792 o1 0x9de0 40416
%o1 seems rather large.
indeed. What else can I do to help diagnose the problem?
marek
/ Brevbäraren
On Mon, Feb 03, 2003 at 04:40:06PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
Try compiling --with-debug, and starting pike/tpike with -a7 or more.
Ran tpike with -a10, the output is at http://grendel.thanes.org/tmp/log.txt
marek
Looks like you now were bit by the describe_svalue() loads master object bug. Fixed.
/ Henrik Grubbström (Lysator)
Previous text:
2003-02-03 16:56: Subject: Re: Pike 7.4 on Debian/Sparc - a build problem
On Mon, Feb 03, 2003 at 04:40:06PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
Try compiling --with-debug, and starting pike/tpike with -a7 or more.
Ran tpike with -a10, the output is at http://grendel.thanes.org/tmp/log.txt
marek
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marek Habersack -
Xavier Beaudouin