On Wed, Aug 11, 2004 at 09:32:16PM +0200, Falk Hueffner wrote:
> Steve Langasek <vorlon@debian.org> writes:
> > Okay, I've found time to take a closer look at this problem, and you're
> > right that it's related to configure. Specifically, it's related to a
> > buggy and unusable octave:
> > $ octave --version
> > Illegal instruction
> > $ octave -q -f <<EOF
> >> printf(octave_config_info("localfcnfilepath"));
> >> EOF
> > Illegal instruction
> > $
> I can't reproduce this with octave2.1 2.1.57-4 on an ev67. What kind
> of Alpha do you have? What does gdb show on disas?
It's an ev56 (same as escher, btw, but probably not lully).
(gdb) run --version
Starting program: /usr/bin/octave --version
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 7477)]
Program received signal SIGILL, Illegal instruction.
[Switching to Thread 16384 (LWP 7477)]
0x00000200017fd3f8 in fftw_import_system_wisdom () from /usr/lib/libfftw3.so.3
(gdb) Dump of assembler code for function fftw_import_system_wisdom:
0x00000200017fd3c0 <fftw_import_system_wisdom+0>: ldah gp,3(t12)
0x00000200017fd3c4 <fftw_import_system_wisdom+4>: lda gp,-3240(gp)
0x00000200017fd3c8 <fftw_import_system_wisdom+8>: lda sp,-32(sp)
0x00000200017fd3cc <fftw_import_system_wisdom+12>: ldq t12,-31208(gp)
0x00000200017fd3d0 <fftw_import_system_wisdom+16>: ldah t0,-2(gp)
0x00000200017fd3d4 <fftw_import_system_wisdom+20>: ldah v0,-2(gp)
0x00000200017fd3d8 <fftw_import_system_wisdom+24>: stt $f2,8(sp)
0x00000200017fd3dc <fftw_import_system_wisdom+28>: stt $f3,16(sp)
0x00000200017fd3e0 <fftw_import_system_wisdom+32>: stq ra,0(sp)
0x00000200017fd3e4 <fftw_import_system_wisdom+36>: lda a0,-25796(t0)
0x00000200017fd3e8 <fftw_import_system_wisdom+40>: lda a1,-26023(v0)
0x00000200017fd3ec <fftw_import_system_wisdom+44>: jsr ra,(t12),0x200017fd3f0 <fftw_import_system_wisdom+48>
0x00000200017fd3f0 <fftw_import_system_wisdom+48>: ldah gp,3(ra)
0x00000200017fd3f4 <fftw_import_system_wisdom+52>: itoft v0,$f2
0x00000200017fd3f8 <fftw_import_system_wisdom+56>: lda gp,-3288(gp)
0x00000200017fd3fc <fftw_import_system_wisdom+60>: clr v0
0x00000200017fd400 <fftw_import_system_wisdom+64>: ftoit $f2,t1
0x00000200017fd404 <fftw_import_system_wisdom+68>: beq t1,0x200017fd438 <fftw_import_system_wisdom+120>
[...]
So, this looks like fftw3 has been incorrectly built to use optimized
instructions specific to the ev67?
Looking at the build log....
checking whether gcc accepts -O3 -fomit-frame-pointer -fno-schedule-insns -fstrict-aliasing -mcpu=ev67... yes
Yep, that looks like a misbuild. :P
I'll try rebuilding fftw3 here to verify whether it makes a difference,
then work up a patch for fftw3 if so.
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature