[WitchTech 00267] Re: LSI-CforWitch の関数ポインタ

[Akira Kawamata <autumn@piedey.co.jp>]

　川俣です。

> この辺、コンセンサスが取れてないようなので、
> 以下にfarで暴走するコードを書いときます。
> 文法上タブンあってます(^^;
　Turbo-C 2.0でも暴走しました。
　テストプログラムを少し修正してみました。(Turbo-C only)

#include <sys/bios.h>
#include <stdio.h>

char (far *tmp_func)(int no);

char far t1(int no);

void main() {
	static char str[32];
	unsigned int cs,ip;
	unsigned long target;

	cs = _CS;
	ip = (unsigned int)t1;
	target = ((unsigned long)cs << 16L) | (unsigned long)ip;

	text_screen_init();
	text_put_string(0, 0, "start");

	tmp_func = t1;
	sprintf(str, "%08lx %08lx", tmp_func, target);
	text_put_string(0, 1, str);

	while(1)
		if(key_press_check() == KEY_START)
			break;
}

char far t1(int no) {
	return no + 1;
}

　実行結果は

00000141 9CA00141

　となりました。具体的な数値は環境によって違うかもしれません。しかし、変
数tmp_funcの上位16bitがゼロであるのは、どう考えても異常です。
　直接t1を呼び出すと正常に呼べますが、

	tmp_func = t1;

　として関数のアドレスを変数に得ると、値がおかしいようです。
　コンパイラにアセンブラソースを吐かせて、TASMでアセンブルすると、こんな
感じです。

    131 0030  C7 06 0022r 0000s              mov     word ptr DGROUP:_
tmp_func+2,seg CGROUP:_t1
    132 0036  C7 06 0020r 0080r              mov     word ptr DGROUP:_
tmp_func,offset CGROUP:_t1

　上の行の0000sは、アセンブラでは確定できないセグメントの値だと思います。
　ですが、この値は、リンカでも確定できるわけがないので、実際にはOSのロー
ダが確定させるものだと思います。ということで、OSの実行ファイルローダも怪
しいと思われます。
　TCでもLSI-Cでも同じ症状が出ることから考えると、コンパイラ、リンカのバ
グという確率は低いように思われます。どちらかといえば、FreyaOSのバグとい
う可能性が濃いように思います。
　というわけで、バグレポートした方がいいかもしれません。

(株)ピーデー 川俣 晶 (http://www.autumn.org/ mailto:autumn@piedey.co.jp)