アセンブラ初心者スレッド 2©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/04/13(木) 17:35:55.70

初心者OK！質問大歓迎！のアセンブラのスレッドです。
基本情報の勉強中の人、PICやH8を勉強中の学生などなど…

前スレ
アセンブラ初心者スレッド
http://echo.2ch.net/test/read.cgi/tech/1314502612/

関連スレ
アセンブラ 13
http://echo.2ch.net/test/read.cgi/tech/1314512680/

**デフォルトの名無しさん** · 2018/09/29(土) 16:24:58.15

>>307
x86_64をわかってないのはあなただろ
MASMでは
mov rax, hogehoge
こう書く仕様だっての

gcc、gasでは
mov rax, hogehoge[rip]
こう書くのが仕様

ただそれだけ
マシン語ではどちらも48 8b 05 xxxxxxxxとRIP相対の32bitDISPになる

**デフォルトの名無しさん** · 2018/09/29(土) 16:32:57.40

offsetを使ったものも

MASMでは
mov rax, offset hogehoge
これでマシン語は48 b8 xxxxxxxxxxxxxxxxと64bit絶対アドレスになる

gcc、gasでは
movabs rax, offset flat: hogehoge
これでマシン語は48 b8 xxxxxxxxxxxxxxxxと64bit絶対アドレスになる

leaを使うと
MASMでは
lea rax, hogehoge
これでマシン語は48 8d 05 xxxxxxxxとRIP相対32bitDISPになる

gcc、gasだと
lea rax, hogehoge[rip]
これでマシン語は48 8d 05 xxxxxxxxとRIP相対32bitDISPになる

**デフォルトの名無しさん** · 2018/09/29(土) 16:43:03.59

x86_64のRIP相対アドレッシングは歴史的には
32bitの時の32bit絶対アドレッシングの仕様を変更してRIP相対をねじ込んだ形だからね
アセンブラの記述的に、論理的におかしくてもしょうがないんだよ
論理的なものよりも実用性を重視したのがMASM
より論理的に厳密にしたのがgasということだろうな

**デフォルトの名無しさん** · 2018/09/29(土) 17:11:34.41

ちょっと質問なんだけど
dataセクションは32bitアドレス内にないとアクセスできないってこと？

extern int aaa[10];
int bbb (int i) {return aaa[i];}

このコードがこんな感じになってたんだけど

00000000004011a0 <bbb>:
4011a0: 48 63 ff movslq %edi,%rdi
4011a3: 8b 04 bd 40 40 40 00 mov 0x404040(,%rdi,4),%eax
4011aa: c3 retq

aaaがdataセクションの0x404040にあったからこうやってアクセスできたけど
32bit超えてたらこの命令は翻訳できない？

**デフォルトの名無しさん** · 2018/09/29(土) 17:23:41.07

>>311
アセンブラのみではそういうことはないけど、C言語とリンクする場合はそうなるね
64bitでも通常はグローバル変数などのシンボルやジャンプ先のラベルは32bitを前提としてコンパイルされている
x86_64だとRIP相対の32bitDISPで届かないところにはアクセスできない
他のCPUでも似たようなもの

Windowsだと回避方法はない
LinuxだとHPCなどで-mcmodel=mediumを指定することで回避できる方法はあるけどね

**デフォルトの名無しさん** · 2018/09/29(土) 17:34:12.56

>>290
首席のことか

**デフォルトの名無しさん** · 2018/09/29(土) 17:35:24.77

>>311を俺の環境でgccでコンパイルしてみたらこうなった
オブジェクトファイルなのでアドレスは00 00 00 00のまま
gccのバージョンは7.3.0

0000000000000000 <bbb>:
0: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # 7 <bbb+0x7>
7: 48 63 ff movslq %edi,%rdi
a: 8b 04 b8 mov (%rax,%rdi,4),%eax
d: c3 retq

**デフォルトの名無しさん** · 2018/09/29(土) 17:36:30.80

ありがとう
>>311のはa.outにしてアドレスが分かるようにした後だったから

**デフォルトの名無しさん** · 2018/09/29(土) 17:37:16.65

AT&Tニーモニックの貼ってしまった

Intelニーモニックはこっち
0000000000000000 <bbb>:
0: 48 8d 05 00 00 00 00 lea rax,[rip+0x0] # 7 <bbb+0x7>
7: 48 63 ff movsxd rdi,edi
a: 8b 04 b8 mov eax,DWORD PTR [rax+rdi*4]
d: c3 ret

**デフォルトの名無しさん** · 2018/09/29(土) 17:42:37.03

一旦axに入れてるんだ
そっちの方が遠くまでアクセスできそう
俺のはlinuxだからかな
gccは8.2.0だけど7.3でも>>311のようになりそう

**デフォルトの名無しさん** · 2018/09/29(土) 18:11:22.67

俺のもLinuxだよ

**デフォルトの名無しさん** · 2018/09/29(土) 18:29:50.29

7.3でも5.3でも>>311のになった
configure 設定: ../gcc-7.3.0/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared
--enable-bootstrap --enable-languages=ada,brig,c,c++,fortran,go,lto,objc --enable-threads=posix --enable-checking=release
--enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --enable-lto --disable-install-libiberty --with-gnu-ld --verbose --with-arch-directory=amd64
--disable-gtktest --disable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux
スレッドモデル: posix
gcc バージョン 7.3.0 (GCC)

configure 設定が違うのかな

**デフォルトの名無しさん** · 2018/09/29(土) 18:31:39.06

>>303
>mov rax, hogehoe
>これが*(rip + hogehoge)の意味

それは明らかに間違っているよ。

正しくは、>>281 のように、

MASM だと 64bit mode で
　　mov rax, hogehoge
と書くと、
　　mov rax, [rip + (offset hogehoge - offset label1)]
label1:

の「意味」になって(ただし、実際の masm ではこの書き方はエラーになるはず)、

C言語で書けば、
rax = *( rip + (&hogehoge - &label1) )
label1:

の「意味」になる。

**デフォルトの名無しさん** · 2018/09/29(土) 18:37:57.88

>>320
理解のポイントは、(64BIT)命令ポインタ rip は、CPUが、ModRM
の間接(メモリ)オペランドを解釈する時には、命令の直後の
アドレスを指しているかのようにみなされて、丁度、

rip = offset label1

または、

rip = &label1

であるかのように解釈されるということ。

**デフォルトの名無しさん** · 2018/09/29(土) 18:52:23.15

>>320
RIP相対32bitDISPって書いてるんだからわかってるんだよ、そんなこと
わかりきったことをしたり顔で書いてんじゃねーよ

**デフォルトの名無しさん** · 2018/09/29(土) 19:02:53.64

>>319
自分でビルドしたやつじゃないけど
gcc -vをやると
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)

**デフォルトの名無しさん** · 2018/09/29(土) 19:23:24.57

分かった-fPICつけると>>314と同じになった

**デフォルトの名無しさん** · 2018/09/29(土) 19:30:06.39

MASMはデフォルトがrip相対だからな
offset演算子使った段階でアドレスではなくただの数値になってるのが理解できんのか
だから絶対アドレスになんだよ

**デフォルトの名無しさん** · 2018/09/29(土) 19:42:48.86

>>325
ただの数値じゃないぞ
だって再配置される時に64bitの絶対アドレスが再配置されたアドレスに置き換わる
だからただの数値じゃない、64bit絶対アドレスとして認識されてるはず

**デフォルトの名無しさん** · 2018/09/29(土) 19:54:13.97

変な突っ込みする人がいるから書くが
CPUの命令的にはx86_64で
mov rax, offset hogehoge
これは64bitのimmを読み込むマシン語に変換される
要するにただの64bitの数値を読み込む命令
マシン語は48 b8 xxxxxxxxxxxxxxxx
ただ、アセンブラはちゃんと64bit immの部分が64bitの絶対アドレスということを認識してる
だから再配置された時に64bit絶対アドレスが再配置後のhogehogeのアドレスに置き換わる

**デフォルトの名無しさん** · 2018/09/29(土) 20:19:25.44

こんなことみんな知ってるとは思うが
実際に64bit絶対アドレスが確定するのはプログラムがメモリ上にロードされる時
このときに、絶対アドレスなどの情報が配置されるアドレスによって正しい値に書き換えられる

**デフォルトの名無しさん** · 2018/09/29(土) 21:07:16.90

そもそも
lea rax, [hogehoge]
って書いときゃNASMでも通るのに
＞data01のアドレスを読み込みたかったら
＞mov eax, offset data01
＞こうすること
なんて教えようとするのかね？

**デフォルトの名無しさん** · 2018/09/29(土) 21:11:28.97

MASMって
mov eax, [rsp][16]
mov eax, [rsi][rcx]
みたいな変態な表現も通るんだよな

**デフォルトの名無しさん** · 2018/09/30(日) 00:47:29.69

Microsoft (R) Macro Assembler (x64) Version 12.00.40629.0
mov al, hogehoge
mov al, [hogehoge]
mov rax, offset flat:hogehoge ; error A2006:undefined symbol : flat
lea rax, [hogehoge]
lea rax, offset flat:hogehoge ; error A2006:undefined symbol : flat
lea rax, hogehoge

14.00.24210.0でも同じだな

**デフォルトの名無しさん** · 2018/09/30(日) 00:54:08.42

clが吐いた.codでは
lea rax, offset flat:hogehoge
みたいな表記になってるけど、ml64は受け付けない

**デフォルトの名無しさん** · 2018/09/30(日) 01:03:38.57

mov eax, offset hogehoge
とやってもエラーも出ないんだよね　当然だけど
0000001A 48/ B8　0000000000000000 E　mov rax, offset hogehoge
00000024 B8 00000000 E mov eax, offset hogehoge

**236** · 2018/09/30(日) 01:18:13.92

なんか説明が不適切だったせいで偉いことになってしまった・・・すまん

とりあえずAMD64のプログラミングマニュアルとIA32/EM64Tの日本語プログラミングマニュアルはダウンロードしてあります

やりたいことは演算ではなくて特殊？な例外処理です。C風に書くと
unsigned int *a;
unsigned int b;
&a = 0x00001000; // アドレスをセット
*a = 0x00888888; // 0x00001000へ値を書き込み
b = *(&a + 1); // 0x00001004の値を読み出し。読み出される値は0x00001000の値に0x0100を加算した物
// bの中身は0x00888988
みたいな感じかな。メモリの読み書き動作に任意の処理を挟みたいです。自分なりにこのような動作をさせる方法を考えた結果
・該当する仮想アドレスにメモリを割り当てない
・アクセスすると発生するページフォールトをハンドリングする
・ハンドラ中で値の処理とアクセス元のコードが行うつもりだった読み書き動作もする
・ページフォールトを発生させた次の命令から実行を再開する
となったのですがこれらを高級言語のみで実装するのは無理そうな気がするのでアセンブラを読み書きできる必要があるかなと・・・
各OSごとの例外処理がらみの情報も必要ですがこの辺もなかなか見つけられないです

**デフォルトの名無しさん** · 2018/09/30(日) 04:51:47.08

>>322
64bitのcl.exeが吐き出すアセンブラ出力はml64.exeでそのままではアセンブル通らないよ
何箇所か、修正が必要になる
ちなみに32bitのcl.exeが吐き出すアセンブラ出力はそのまま32bitのml.exeでアセンブルできる

>>333
mov eax, offset hogehoge
これをx64用のml64.exeでアセンブルしてもエラーは起きないが
リンク時にこのエラーが出るよ
error LNK2017: 'ADDR32' relocation to
'hogehoge' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors
64bitのアドレスを32bit絶対アドレスに切り詰めてるのだから当たり前だけど

mov rax, offset hogehoge
これは全く問題ない
アセンブルもリンクも正常に行われるし、正常にプログラムを実行できる

**デフォルトの名無しさん** · 2018/09/30(日) 17:26:28.46

>>335
NASM（bits64, default rel）だとエラーになるよ
mov rax, offset hogehoge ; error: comma, colon, decorator or end of line expected after operand
lea rax, hogehoge ; error: invalid combination of opcode and operands
lea rax, [hogehoge] ⇒ 488D05

mov al, hogehoge ⇒ B0
にアセンブルされたりもするけど

MASMでもlea rax, [hogehoge]やmov al, [hogehoge]はNASMと同じマシン語になるはず

Windows 64bitはrip相対使ってるのに、MASMで簡単に絶対アドレスが登場するのがおかしいと思わないのかね

**デフォルトの名無しさん** · 2018/09/30(日) 21:29:51.77

>>334
いまいちやりたいことが分からないんだけど、Windowsでアクセス違反をハンドリングするのは
https://docs.microsoft.com/ja-jp/windows/desktop/Memory/reserving-and-committing-memory
が参考になるんじゃないかな
__except()のフィルタ関数でアクセス違反をチェックして、対象範囲のアドレスだったらVirtualAllocで
コミットして__except()にEXCEPTION_CONTINUE_EXECUTION返せば再実行される
対象範囲外のアドレスはEXCEPTION_CONTINUE_SEARCHを返す必要がある
メモリは事前に予約してないと例外から回復できないみたい

構造化例外処理は
http://www.ne.jp/asahi/hishidama/home/tech/vcpp/seh.html
https://msdn.microsoft.com/ja-jp/library/swezty51.aspx
を読んでみて

**デフォルトの名無しさん** · 2018/10/01(月) 04:48:19.14

>>336
LinuxのNASMとMASMは構文違うよ

NASMだと
mov rax, hogehoeg
マシン語は48 b8 xxxxxxxxxxxxxxx
これでraxにアドレスが入る

WindowsのMASMだと
mov rax, hogehoge
マシン語は48 8b 05 xxxxxxxx
hogehogeのメモリの内容がraxにロードされる
MASMの場合、
mov rax, offset hogehoge
これだとマシン語は48 b8 xxxxxxxxxxxxxxxx
これにしないとNASMのmov rax, hogehogeと同じマシン語にならない

**デフォルトの名無しさん** · 2018/10/01(月) 05:43:56.26

みんなはじめて読むMASMからやり直しだなｗ

**デフォルトの名無しさん** · 2018/10/01(月) 05:51:48.63

>>336
RIP相対32bitdispだとアクセスできない場合が出てくる
シンボルがRIP相対2GBに制限されるなどはあくまでCコンパイラの制限であって
アセンブラはその制限を受けない
実際にWindowsのEXEファイルは64bit絶対アドレスに対応してて
きちんと再配置してくれるわけだし

**デフォルトの名無しさん** · 2018/10/01(月) 06:38:07.64

これこそアスペって奴だよな
質問とは関係ないCPU持ち出して勝手に「語り」をはじめたり、32bitでは1バイト短くなるだの
実用的には0.001%程度しか影響なさそうな絶対アドレスの方が速いだの、C/C++とリンクして使うのが
普通なのに「シンボルがRIP相対2GBに制限されるなどはあくまでCコンパイラの制限であってアセンブラはその制限を受けない」とか
初心者そっちのけで有害としか思えないような方法垂れ流したりと、他人の迷惑とか全く考えられないんだから

初心者にはMASMとNASMで同じように使えればそれで十分
完全に同じマシン語になるかどうかなんて知るか
特に絶対アドレスなんてWin64には不要と考えるべき
初期化領域以外の動的確保されたメモリはポインタ経由のアクセスが基本なんだから

**デフォルトの名無しさん** · 2018/10/01(月) 06:45:27.19

>>334
こういう状態なんで、334は全く悪くないから気にしなくていいよ

アクセス違反を検出して対応するのは、使ってみたいところがあったのでちょうどいい機会だった
一応自分の書いたテストプログラムを上げとくね
https://pastebin.com/b5gZXxCF

**デフォルトの名無しさん** · 2018/10/01(月) 06:51:19.23

>>341
>>338が理解できないのか？
LinuxのNASMとWindowsのMASMは根本的に文法が違う
同じようにはプログラミングできないっての

MASMではMS-DOSの頃から伝統的に
mov ax, hogehoge
これをやるとhogehogeのメモリの内容をaxに読み込む
はじめて読むMASMにもそう書いてあるよｗ

**デフォルトの名無しさん** · 2018/10/01(月) 07:02:13.01

はじめて読むMASM
79ページ目
　データラベルは、マシンご命令のニーモニックのなかで、データを格納す
るメモリを参照するために使用することができます。次の図３－１０をみてく
ださい。この図では、違いを対比させるために次節で解説するOFFSET擬似
命令の役割を併せて図解してあります。
　この場合、MESSAGEというデータラベルは01C3Hというアドレスに対応
しています。コードラベルの場合は、ラベル名がアドレスそのものと対応し
ていましたが、データラベルの場合にはちょっと違います。このことは重要
ですからよく覚えておいて下さい。
　たとえば、SYMDEBのようにアドレスを直接数値で指定する場合、そのア
ドレスのメモリの内容を参照するには、
　MOV DX, [01C3H]
のようにアドレスを［］で囲みます。これに対し、アセンブラのソースプロ
グラムでは、
　MOV

**デフォルトの名無しさん** · 2018/10/01(月) 07:04:42.69

はじめて読むMASM
79ページ目
　データラベルは、マシンご命令のニーモニックのなかで、データを格納す
るメモリを参照するために使用することができます。次の図３－１０をみてく
ださい。この図では、違いを対比させるために次節で解説するOFFSET擬似
命令の役割を併せて図解してあります。
　この場合、MESSAGEというデータラベルは01C3Hというアドレスに対応
しています。コードラベルの場合は、ラベル名がアドレスそのものと対応し
ていましたが、データラベルの場合にはちょっと違います。このことは重要
ですからよく覚えておいて下さい。
　たとえば、SYMDEBのようにアドレスを直接数値で指定する場合、そのア
ドレスのメモリの内容を参照するには、
　MOV DX, [01C3H]
のようにアドレスを［］で囲みます。これに対し、アセンブラのソースプロ
グラムでは、
　MOV DX, MESSAGE
とします。このことからわかるように、データラベルはラベルに対応するア
ドレスそのものではなく、そのアドレスが示すメモリの内容を表します。
つまり、データラベルそのものを指定すると、アドレスの値を転送したり演算
したりする命令ではなくて、メモリに対して転送や演算を行う命令になりま
す。もう1度図３－１０を見てじっくり確認してください。

こう書かれてる

**デフォルトの名無しさん** · 2018/10/01(月) 07:10:06.78

82ページ目

３．６
OFFSET演算子とPTR演算子
OFFSET演算子
[書式]　OFFSET　ラベル名

データラベルをニーモニック中で使用すると、データ部分のアドレスでは
なく、データを格納したメモリの内容を表しますが、そのメモリのアドレス
はどうやって表すのでしょうか。図３－１０で図解してあるので解説するまでも
ありませんが、データラベルに対応するアドレスは、次のように表します
　OFFSET データラベル
　OFFSET演算子は、ラベルに対して使用する演算子です。ラベルの前にこ
の演算子を付けると、ラベルに対応するアドレスを表す値となります。
　例題のプログラムでは図３－１１の部分で使われています。これは画面に出
力するメッセージが格納されているアドレス値を、データとして定義してい
る例です。

MASMの文法は16bitの頃から一貫してる
みんなはじめて読むMASMからやりなおしだな

**デフォルトの名無しさん** · 2018/10/01(月) 07:41:22.29

>>343
MASMでもmov al,[hogehoge]やlea rax,[hogehoge]が使えて、NASMと「同じ動作」が期待できて、
「根本的に」書き換えなくても疑似命令やマクロとかを書き換えれば移植できるってのがポイントで
NASMはLinux他とWindowsみたいなマルチプラットフォームのプロジェクトでよく使われてるから
あんたみたいなmov al,hogehogeやり方でNASMに移行すると変なバグに悩まされる可能性があんだよ
特にmov al,hogehogeがイミディエイトでアドレスの一部がコードされるのが酷い

SYMDEBで括弧で括るってのはイミディエイトと区別付かないからそうなってるんだろ
これはNASMで括弧で括るのと同じこと
時代遅れになった本の内容なんてどうでもいい
括弧で括らない表記は、8080時代を踏襲してるのか、インラインアセンブラでのCの変数参照と統一感があるってところだろう
これならNASMで異なる動作にならない方が無難

こっちが言いたいのは、初心者に有用なことが書けないなら「出てくんな」ってことだけ

**デフォルトの名無しさん** · 2018/10/01(月) 07:55:48.93

>>347
それは自分だけで書いたコードを読むだけならいいが
他人が書いたコードやコンパイラが吐き出したコードを読むのにはそれは通用しない

**デフォルトの名無しさん** · 2018/10/01(月) 07:57:49.96

それにNASMで慣れるとgccでインラインアセンブラを使うときに困る
gccはx86_64でもインラインアセンブラを扱えるのに
NASMの文法はgccのインラインアセンブラでは通用しないぞ

**デフォルトの名無しさん** · 2018/10/01(月) 08:10:48.59

多くの人がOFFSET演算子に対する理解がないようだから書いただけなのに
猛烈に反発してくる変な人がいるだけ

gccでは-mcmodel=largeのオプションを付けてコンパイルすると
movabs rax, offset flat: hogehoge
のような表現がよく出てくる
64bit絶対アドレスを扱うには必ず必要になってくる

**デフォルトの名無しさん** · 2018/10/01(月) 09:35:33.25

>>341
アセンブラは、かなり細かいことを理解して無いと使いこなせないかもしれないよ。
それが C/C++ などとは違う点。

ちゃんと、リストファイルを見て、Intel の Instruction 表と照らし合わせて
どの命令が出力されているかを確認し、さらに、OBJやEXEファイルを逆アセンブル
してみて、さらにさらに、ローダーが実際にどのようにロードしたかをデバッガ
で確認する、などをちゃんとしないと、うまくいかないかもしれない。

実際、純正の Visual Studio が出したアセンブリソースが、masm で通らない
などという現象が確認されている事からしても、色々と確認作業が必要だと
思う。

自分はアセンブリ経験が豊富だが、上記のような確認作業をかなり積んだから
こそ使えていたと思う。

アセンブラの出力は、バージョンによっても違っていることがあるかも
知れないし、64BITモードでは、同じニモニックでも異なるマシン語を
出力することもありえる。

さらに言うと、アセンブラ自体が非常に困った仕様になってしまっていることもあり得る。

もともと、アセンブリ言語は、初心者が混乱無く使えるようにはなってないという側面もある。

失礼かもしれないけど、他の言語で豊富な経験を積んで、なおかつ、地頭のいい人限定だよね、もともと。

**デフォルトの名無しさん** · 2018/10/01(月) 09:38:14.45

あと、一度実験した内容を正確に覚える記憶力も必要。

本で書かれていることと実際が違っていることは良くある。

**デフォルトの名無しさん** · 2018/10/01(月) 10:13:48.86

>>334
例外処理については、詳細な文献と実験調査を行ったことがある。

文献だけでは不十分で、コードをフックするような仕組みによって実験しないと分からない。

教えることは出来るが、ここでは馬鹿にされるだけなのですまんが答えられない。

**デフォルトの名無しさん** · 2018/10/01(月) 10:26:50.53

IDを換えながらレスをつけてるのか

**デフォルトの名無しさん** · 2018/10/01(月) 23:50:29.17

>>353
Windows用のサンプルは>>342でupしてるので、Linuxは任せたｗ

**デフォルトの名無しさん** · 2018/10/02(火) 07:08:08.55

>>334
Windowsならちょっとググッただけでいろいろ出てくるぞ
このあたり見てやればできるのでは？
アセンブラは全く関係ないね

構造化例外処理
http://www.ne.jp/asahi/hishidama/home/tech/vcpp/seh.html
GetExceptionCode
https://msdn.microsoft.com/ja-jp/library/cc428942.aspx

**デフォルトの名無しさん** · 2018/10/02(火) 07:14:31.94

あとこれも

構造化例外処理と UnhandledExceptionFilter
https://www.keicode.com/windows/windows_exception_handling.php

**デフォルトの名無しさん** · 2018/10/02(火) 07:41:02.78

これも

構造化例外処理～例外情報の取得
https://www.keicode.com/windows/structured_exception_handling.php

**デフォルトの名無しさん** · 2018/10/02(火) 08:43:48.77

ただ、例外のハンドリングはできても、処理を続行するのは難しいね
EXCEPTION_CONTINUE_EXECUTION を返すと処理は続行されるけど
例外が発生するところから続行されるからね
例外が発生したところの次の命令から続行されるわけじゃないからね

**デフォルトの名無しさん** · 2018/10/02(火) 14:17:43.67

>>359
次の命令からでも、続行する方法あるよ。

**デフォルトの名無しさん** · 2018/10/02(火) 18:27:14.93

アセンブラが難しすぎて読めません
https://gyazo.com/ba3099329df9872df87fa3c35ff13384
これはFPSの弾数周辺のアセンブリなんですが、どういう処理をしてるのか全く分かりません
どういう風に読んでいけば理解できるのか？ヒント下さい
ニーモニックは何となく分かるんですけど・・

**236** · 2018/10/02(火) 23:02:45.96

ありがとう。やりたいことはメモリマップドI/Oのエミュレーションです。なので呼び出し元のコードはなるべく細工したくありません

例外ハンドラでメモリを確保してしまうと2回目以降や隣接するアドレスのアクセス時に例外が発生しなくなってしまうので避けたいです
あとWindowsで>>334をやろうとした場合0x00001000から8Byteをあける必要がありますが、そのアドレスへデータをロードしないよう
MSVCのリンカへ指示する方法がわかりません
ldやlldなどであればリンカスクリプトで指示できるらしいのですが・・・(OSの候補にLinuxやFreeBSDがいる理由の一つです)

呼び出し元のコードに細工をすれば例外なんてめんどくさい物を使わずにすみますが、エミュレートしないケースの
オーバーヘッドを完全になくせるか心配です。コンパイラの最適化でインライン展開とデッドコード削除が約束されるなら
そっちの方が遙かに楽ですが・・・

**デフォルトの名無しさん** · 2018/10/03(水) 00:49:48.02

>>362
例外機構を使わずに、以下のような方法も場合によっては使える：

1. C++ の演算子の overload を使う方法。
2. Win32のメモリマップド I/O 機能を使う方法。

>あとWindowsで>>334をやろうとした場合0x00001000から8Byteをあける必要がありますが、
>そのアドレスへデータをロードしないよう
>MSVCのリンカへ指示する方法がわかりません

これは、VitualAlloc() で、0x1000 からの 1page(4096 バイト)をアクセス禁止の page に
すると可能。

ただし、8 バイト以外の部分もアクセス禁止になるので、その部分でも、例外ハンドラ
が起動してしまうので、その部分についての処理も例外ハンドラに書くようにする。

**デフォルトの名無しさん** · 2018/10/22(月) 19:17:19.32

最近CASLⅡ覚えた後、実際のマイコンのアセンブリ言語覚えたくてルネサスのRL78も覚えたんだけど(PICはCASLⅡ以前から覚えてはいた)、
x86とZ80を合わせたようなニーモニックだけかと思ったらAをR0、XをR1って別名に出来たりAXがRP0に出来たり、GR0、GR1って書くCASLⅡにニーモニックが似てるんだが。。。

これってもしかして癒着とかじゃあるまいな。
(逆にルネサスがCASLⅡに寄せた可能性も微レ存)

日本車に使われてるらしいし、自動車は国の基幹産業だし(つまりルネサスのお得意様は日本の自動車メーカー)、あり得なくはない。

**デフォルトの名無しさん** · 2018/10/22(月) 19:56:28.08

仮想アセンブラでは、LLVM が標準

**デフォルトの名無しさん** · 2018/10/23(火) 14:50:58.07

病院逝け

**デフォルトの名無しさん** · 2018/10/23(火) 18:22:26.97

もう少し髪が伸びたらな

**デフォルトの名無しさん** · 2018/11/26(月) 21:11:44.08

LLVMネタってここで良いんですかね？

**デフォルトの名無しさん** · 2018/11/30(金) 09:46:12.16

アセンブラの勉強始めていきなり躓いてるのですが、オペランドの記述で
r/m32やimm32やr32やm32って何の略なんですか？
検索しても命令一覧表ばかり引っかかって・・（;´д｀）

**デフォルトの名無しさん** · 2018/11/30(金) 10:47:42.01

r32： 32bit幅レジスタ
m32： 32bit幅メモリ
imm32： 32bit幅即値

**デフォルトの名無しさん** · 2018/11/30(金) 10:53:47.90

命令の内部フォーマットとアドレッシングモード
https://www.mztn.org/lxasm64/amd05.html

**デフォルトの名無しさん** · 2018/11/30(金) 15:33:43.72

>>367
オシャレ

**デフォルトの名無しさん** · 2018/11/30(金) 17:07:23.34

>>368
知ってても答えたくないかも。

**デフォルトの名無しさん** · 2018/11/30(金) 17:26:55.55

>>365
あれは人間が読むコードじゃない

**デフォルトの名無しさん** · 2018/12/02(日) 03:55:19.52

>>370
>>371
ありがとうございます！

**デフォルトの名無しさん** · 2018/12/02(日) 13:54:11.82

LLVM 豆知識。
getelementptr には、似て非なるものが二種類ある。命令タイプと、定数タイプ。
後者は、他の命令のオペランドで用い、括弧でくくるような書き方をする。

仮想レジスタ %n に、整数定数を代入する命令が無い。
それで困った場合は、
　%10 = add i32 定数値, 0
などとすると良い。同様にポインタ定数も直接は代入できないが、
　%10 = getelementptr TYPE, TYPE * アドレス定数, 0
などとすれｂな代入できる。

**デフォルトの名無しさん** · 2018/12/02(日) 14:03:34.88

記憶に頼って書くと、

【命令タイプ】
%n =getelementptr TYPE, TYPE * 値, i32 idx1, i32 idx2, ・・・

【定数タイプ】
getelementptr (TYPE, TYPE * 値, i32 idx1, i32 idx2, ・・・)

getelementptr の他に、bitcast, itoptr, ptrtoi, ftoi, itof, zext, sext にも
全く同様に命令タイプと定数タイプがある。

この事は、Reference Manual には分かりやすくはかかれてないかも知れない。

また、話は変わるが、getelementptr は、配列のような概念を使うので、
アセンブラに慣れた人が、それを使うのが面倒な場合は、bitcast で i8* 型に cast
して計算する方法もある。

TYPE *ptr; に対し、

%R1 = bitcast TYPE * ptr to i8*
%R2 = getelmentptr i8* %R1, offset
%R3 = bitcast i8 * %R2 to TYPE*

とすれば、offset には、sizeof(TYPE) とは全く無関係の
バイト単位のオフセット値を指定できる。

**デフォルトの名無しさん** · 2018/12/02(日) 14:16:20.44

記憶に頼って書く。

【getelementptr 豆知識】

getelementptr は、複雑なことをしているように見えるが、
　%n = getelementptr TYPE, TYPE * ptr, i32 idx
は、C 言語で書くと、
TYPE　　ptr;
に対し、
%n = &(ptr[idx]);
を計算しているに過ぎない。

idx が2つ以上になって、
　%n = getelementptr TYPE, TYPE * ptr, i32 idx1, i32 idx2, i32 idx3
となった場合は、たとえば、TYPE が (n次元)配列の場合は、

%n = &(ptr[idx1][idx2][idx3]);

と同じ。覚えておくことは、アドレス演算子「&」が、最後にだけ付くということ。
この規則は構造体が中に含まれている場合でも全く変わらない。

**デフォルトの名無しさん** · 2018/12/02(日) 14:24:12.50

言いたいことは変わらないが、TYPE が3次元配列の場合には、
TYPE *ptr;　とは、厳密には、
ELEMTYPE (*ptr)[a][b][c];
となってるのだから、やりたいことは、
　%n = &(ptr[0][idx1][idx2][idx3]);
となる。だから、厳密に言うと、
idx を1つ増やす必要があり、
　%n = getelementptr TYPE, TYPE * ptr, i32 0, i32 idx1, i32 idx2, i32 idx3
となる。

規則性は、よく考えると分かる。

**デフォルトの名無しさん** · 2018/12/02(日) 14:27:39.98

>>378
誤： TYPE　　ptr;
正： TYPE　　*ptr;

**デフォルトの名無しさん** · 2018/12/08(土) 22:09:51.24

LLVMのフロントエンドとバックエンドの自由度は極めて高い。CPUどころかGPUまである
ということはアーキテクチャAの実行イメージを入力に、アーキテクチャBの実行イメージを出力することも出来そう

と妄想した

**デフォルトの名無しさん** · 2018/12/11(火) 15:12:16.55

>>381
・Windows の EXE の場合、IAT、ILT、THUNK、DLL の名前解決などの LLVM への
　置き換えが果たして可能かどうか。これに関してはもしかしたら難しいかもしれない。

・COFF EXE の場合は可能かもしれないが、データ領域とコード領域を絶対に間違いなく
　区別する必要も有る。

**381** · 2018/12/11(火) 17:56:58.27

>>382
そういう動的な処理の多いシステムは難易度が高いと思うので、ゲーム機のROMイメージを別のプラットフォームで
実行できる実行イメージに出来ないかなと思った。一般的なエミュレータより高効率で動作させられるはず

と妄想した

2019/02/23(土) 13:51:34.34

MIPS　アセンブラ初心者なんだけどおせーて？

asm volatile (“di %0” :“=r” (status));

って　割り込みを拒否して　さらにstatusに現在の割り込み設定を退避させてるって意味でええの？

**デフォルトの名無しさん** · 2019/02/24(日) 09:52:41.67

>>384
日本だと、8080, Z80, 6804(?), 68000, 8086, 80386(IA32) なら
答えられる人は少数なりにもある程度いるが、MIPSは難しいかもね、人数的に。

**デフォルトの名無しさん** · 2019/02/24(日) 09:54:36.33

誤：6804
正：6809

多分、日本のパソコン文化の主流は、8080, Z80, 8086, 80386(IA32) だったと
思う。書くと反感買うと思うけど、少数派として、6809, 68000 があった、
という認識。

**デフォルトの名無しさん** · 2019/02/24(日) 10:35:05.00

6502....

**デフォルトの名無しさん** · 2019/02/24(日) 11:13:53.47

>>385
そうなんだ

システムのプログラムフラシュ領域への自己書き込み

のインラインアセンブラシーケンスで使ったんだけど

プログラム追ってみたら割り込み許可情報のデータ退避して復帰してる感じだった

無事マイコンの自己プログラミングできた

ありがとう

**デフォルトの名無しさん** · 2019/02/24(日) 14:37:48.95

>>387
+1
変態め

**デフォルトの名無しさん** · 2019/02/24(日) 14:42:53.37

日本でMIPSだとプレステが有名だが・・・

**デフォルトの名無しさん** · 2019/02/26(火) 17:30:06.50

z80,68000,ia32 ならちょっとわかる

**デフォルトの名無しさん** · 2019/02/27(水) 15:03:03.39

x86でNASMでELFを組んで学習しているのですが、_startの処理でstack frame設定の処理に質問があります
_startからジャンクデータを残さずEIP,ESPを整えて_exitを呼び出す方法を教えてください
（#立つ鳥後をEAX/EIP以外濁さず、を行いたい理由があります）
_exitはnoreturnで、int 0x80によるsystem_call()、又はSYSENTER(0f 34)によるia32_sysenter_target()
を用いて、SYSCALL_VECTOR又はMSR_IA32_SYSENTER_EIP(0x176)が呼ばれます
通常の_startにおけるlibcの処理では、auxvの中、AT_SYSINFO_HEDR(33)から、vDSO内の
__kernel_syscall_via_epcを経てカーネルへ向かうとの説明です
EXTERN _exit
GLOBAL _start
SECTION .text
_start:
push dword 42
call _exit
をnasm -f elf x.asm; gcc -Wall -s -nostartfiles x.o -o x.outで動きますが、
gccの方でlibgcc.a(-lgcc)やlibc(-lc)が自動で追加されるからなので、
-nostdlibや-nodefaultlibsではSegfaultします。ここの処理の理解のためにcrt0.oを眺めていると,
xor %ebp,%ebp ; stack frameの土台を用意
pop %esi ; [argc][argv][envp][auxv]... で一番上のargcをesiに
...（以下_libc_start_main処理）となり最終的に
sys_exit（int 0x80,eax = 1 (sys_exit),ebx = return code）が呼ばれていました
ソースを眺めると、$grep -r "NR_exit[^_]" /usr/include/
/usr/include/asm/unistd_32.h:#define __NR_exit 1
/usr/src/linux/include/uapi/asm-generic/unistd.h:__SYSCALL(__NR_exit, sys_exit)から
/usr/include/sys/syscall.hから
/usr/src/linux/arch/x86/kernel/entry_32.S:ENTRY(system_call)まで辿り着きましたが、
gdbでスタックを眺めてもいまいち要領が得ません
流れとして、stack->auxv[]->AT_SYSINFO_EHDR->VDSO32_vsyscall->__kernel_vsyscall->CUP依存のコピペ先へ
という理解なのですが…もしかして_start時のスタックの状況に勘違いがあるのでしょうか？
参考にしているのはA Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linuxです

L · 2019/02/27(水) 16:16:22.81

>>392
直感からすると、原因は、esp に一度も値を設定していないことが最も疑わしい。
stdlib などがリンクされている場合、start up コードの中で、esp の値が
設定された後に、main などの自分のコードへと実行が移されるが、
-nostdlib などを付けた場合、リンク時に指定した entry point から
実行が開始される。今の場合、リンク時に entry point を指定していよう
なので、恐らく、最初の object file であるところの x.o の先頭アドレス
であるところの _start かｒ実行が開始される。

push dword 42 を行ったとき、esp の値が 0 か、または、0x7fffffff などの
値になっているため、segment fault や general protection fault などが
生じると思われる。

ここまでは全て記憶と直感に頼って書いた。

**デフォルトの名無しさん** · 2019/02/27(水) 16:18:53.04

誤：リンク時に entry point を指定していよう
正：リンク時に entry point を指定しないよう

すまないが、あなたの書き込みの全部は読んでおらず、最初の方の
数行を見ての直感で答えた。

**デフォルトの名無しさん** · 2019/02/27(水) 16:23:18.32

>>393
すまん。

esp だけでなく、ss の値も重要。
mov ax,ds
mov ss,ax
などとした方がいいかもしれない。

一番重要なのは、_start: の直後あたりに、

mov esp, (何らかのメモリバッファの底のアドレス)

とする事。メモリバッファは、自分で用意する。
アセンブラ初心者なら、masm なら、db 命令などで領域を静的に
確保し、その最後のアドレスあたりを指定すると良い。

なお、esp を設定するまでは、push, pop, call は行ってはならない。

L · 2019/02/27(水) 16:37:51.36

>>392
「x86」と言っても、OS によって変わってきて、Windows などなら、確か、
ライブラリを全くリンクしない場合でも、最初から esp は、一応、
「使える状態」に設定されていたと(心の中に)記憶している。
つまり、esp は、最初からOSが用意した何らかのメモリ・ブロックの底に
設定された状態で exe の実行が開始されると思う。

組み込みなどでは、esp の値は 0 みたいな値になっているかもしれない。

L · 2019/03/04(月) 12:10:03.33

>>392
gdb が使える状態なら、
・レジスタ ss, esp がちゃんと「正しい」値になっているかチェックする。
・ss == ds なのか、ss = 0 なのか、ss は 0 ではないか、ds とは別の値なのか。
・call _exit の部分の飛び先アドレスがちゃんと正しい相対アドレスになっているか
　確認する。---> 正しくリンクされていない場合もあるため。

_exit 関数が shared library の中にあるような場合、処理系によって call 文がどのような
マシン語になるかは変わってくる場合がある。リンカが、call [addr] 形式の indirect call
を想定する場合と、
call import_func
・・・
import_func:
jmp [_exit_entry]
・・・
_exit_entry dd _exit

などのようになる場合など、さまざま。それが正しくなっているかの確認も必要。

**デフォルトの名無しさん** · 2019/07/04(木) 19:46:17.60

今時のIA32コードを吐く処理系がよく使う命令についてのまとめた資料ってないですかね
486DXあたりでもかなりの命令数になりますが現行で使われている命令は限定されますよね？

**デフォルトの名無しさん** · 2019/07/05(金) 11:29:01.09

>現行で使われている命令は限定

何言ってんだ

**デフォルトの名無しさん** · 2019/07/05(金) 19:14:34.33

x86系は現行のアーキテクチャとしては間違いなくカオス組。解析器とか作りたくねー

**デフォルトの名無しさん** · 2019/07/21(日) 02:41:27.70

intelで公開している奴じゃなくて？

**デフォルトの名無しさん** · 2019/10/06(日) 15:58:10.24

x86 の条件付きジャンプ命令

JG Greater
JL Less
JE Equal
JNE Not Equal
は分かったのですが、
JA
JB
は何の英単語の略なんでしょうか？

**デフォルトの名無しさん** · 2019/10/06(日) 16:06:45.50

aboveとbelowだったかな

**デフォルトの名無しさん** · 2019/10/06(日) 17:14:52.78

おお、なるほど！
素早いご回答ありがとうございます

**デフォルトの名無しさん** · 2019/10/06(日) 17:29:21.50

https://codeday.me/jp/qa/20190731/1353200.html
おかげさまでこちらのページを見つける事ができました
間違いないようです

**デフォルトの名無しさん** · 2019/10/06(日) 17:30:39.06

昔は常識だった

**デフォルトの名無しさん** · 2019/10/21(月) 09:51:46.99

アセンブラ買ったらリファレンス一冊ついてたしな...
今ならintelのpdf先に見る所?