この件について。悪いのはGCCじゃなく,Numeric Processing Extension coprocessor が見えていたかいないかだった。
以前,
で悩んだとき,GENERIC kernelだと問題は解決していた。そのときの違いはnpxが見えていたかいなかったかである。hayate% /usr/bin/cc /tmp/test.c :0: internal compiler error: in real_to_decimal, at real.c:1621
自分のcustormizeしたkernel configではacpi上のnpxだけを参照して,isaバス上のnpxを見ないように設定していたが,このkernelをVMware Player上のvmで起動するとnpxが見えない。
nativeで起動したときのdmesg
npx1 at acpi0 (FPU, PNP0C04) npx1: io 0xf0 irq 13 npx1: reported by CPUID; using exception 16
VMware Player上で起動したときのdmesg
(acpi0上にnpxは見えない)npx0 at isa0 port 0xf0-0xff npx0: reported by CPUID; using exception 16
Architectureは全然わからず原因はわからないが,とりあえずは以下のconfigを追加したままkernelをbuildすることを忘れないこと。
# ISA bus support
isa0 at mainbus?
# Math Coprocessor support
npx0 at isa? port 0xf0 irq 13 # x86 math coprocessor
この環境がいかに馬鹿げているかをわかっていただけたら嬉しいです。
やっていること。
hayate% uname -a
NetBSD hayate 4.99.40 NetBSD 4.99.40 (HAYATE) #1: Wed Dec 5 21:54:46 JST 2007
root@hayate:/usr/src/devel/obj/sys/arch/i386/compile/HAYATE i386
hayate% cat /tmp/test.c
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("Test\n");
exit(0);
}
hayate% /usr/bin/cc /tmp/test.c
:0: internal compiler error: in real_to_decimal, at real.c:1621
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.NetBSD.org/Misc/send-pr.html> for instructions.
http://releng.netbsd.org/cgi-bin/builds.cgiを見ると2007-12-04 00:02 UTCのi386のbuildは成功しているのでその時点でのバイナリを取ってくるしかないか。
追記
別マシンでつくったgccのオプションを最適化しすぎてVMware Player上では期待された動作をしなかっただけだった。前提の環境条件を忘れていたための単なるポカだった。
追記2 (Jan/01/2008)
npxが見えていなかったために生じた問題だった。http://abekatsu.air-nifty.com/diary/2008/01/post_e722.htmlに追記した。
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
最近のコメント