アカウント名:
パスワード:
惜しい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
よくわからんが (スコア:1)
http://www.e-hdk.com/diary/d201706c.html#22-3 [e-hdk.com]
> これ。 エラーコードが 6 で、書き込み時のページフォールトを表し、アクセス先のアドレスは 0xa。 しかし %rip が指す命令は、全然違うアドレスの読み取り。 そしてちょうど 64 バイト手前にそれっぽい命令があるという形。 この 64 バイトはただの偶然の可能性もあったが、その後も LBR や call 先のズレなどの形で現れたというわけ。 なお、このページフォールトの件ではこの 0x113f57d の直前にジャンプ命令などなく、レジスターの中身を見ても直前までは順番に実行されてきたとしか思えない状態。
キャッシュラインの途中でいきなり死んだ模様
一般的にデコーダにはキャッシュラインサイズのバッファがついていて、命令の切り出しはここから行う
命令キャッシュの出力がこのバッファに入る
x86はキャッシュラインをまたいだ命令がありうるから、最低2個のバッファが必要
分岐をまたいで例えば4wayのデコードするなら、分岐命令があるラインのバッファと、分岐先の命令があるラインの別のバッファが必要
add
bra L1
...
L1:
sub
mul
という列を考えると、addとbraが乗ったラインと、subとmulが乗ったラインを別々のバッファに入れて、2つのバッファから4命令を並列にデコードする
EIRAKU氏の日記のように、キャッシュラインの途中でいきなり変な命令を実行してしまった、というのはどういう場合に起こりえるかというと
1. ラインの途中でデコード対象のバッファが切り替わってしまった
2. 読出し中のバッファの内容が書き換わってしまった
の二つの場合が考えられる
2については、ズレたアドレスのキャッシュラインを読みだして、デコーダが読出し中で排他制御されているバッファのほうに書き込まなければならない
だから2が起きるためにはエラーが二か所同時に発生しなければならない
したがって2より1のほうが可能性は高いと考えている
実際のところどこが悪いのかさっぱりわからんのだがね
Re: (スコア:0)
惜しい