回答編集履歴

3

記述修正

2018/03/13 06:25

投稿

dodox86
dodox86

スコア9183

test CHANGED
@@ -292,7 +292,7 @@
292
292
 
293
293
  ```
294
294
 
295
- 続けて`x/f`を実行。直前でサイズ指定した為にそのサイズがgdbにデフォルト値として保存されるので、正しく表示されます。
295
+ 続けて`x/f`を実行。直前でサイズ指定した為にそのサイズがデフォルト値として利用されるので、正しく表示されます。
296
296
 
297
297
  ```
298
298
 

2

誤字修正

2018/03/13 06:25

投稿

dodox86
dodox86

スコア9183

test CHANGED
@@ -282,7 +282,7 @@
282
282
 
283
283
  ```
284
284
 
285
- `x/8xb`で8バイト分ダンプします。メモリ上の8バイトは正しいことが分かります。
285
+ `x/8xb`で8バイト分ダンプします。メモリ上の8バイトは正しいことが分かります。
286
286
 
287
287
  ```
288
288
 

1

質問者のコメントを受けて再検証したので追記

2018/03/13 06:22

投稿

dodox86
dodox86

スコア9183

test CHANGED
@@ -237,3 +237,89 @@
237
237
 
238
238
 
239
239
  正しく2の平方根である1.41421...が表示されました。
240
+
241
+
242
+
243
+ ---
244
+
245
+ **2018/03/13 追記しました。**
246
+
247
+
248
+
249
+ コメントをいただいたのでこちらでも検証しました。不正な(期待しない)値が表示されたのはコメントでの推測のとおり、gdbのxコマンドの挙動によるもので、メモリ上の対象範囲の解釈の違いが原因です。
250
+
251
+ 結論としては「gdbの使い方の問題」と言えます。
252
+
253
+
254
+
255
+ 以下のとおり、トレースしてみます。
256
+
257
+ 当該プログラムをrunし、`fstl 4(%esp)`の実行直後でブレイクします。
258
+
259
+ ```
260
+
261
+ (gdb)
262
+
263
+ 18 fstl 4(%esp)
264
+
265
+ (gdb)
266
+
267
+ 19 movl $code, (%esp)
268
+
269
+ ```
270
+
271
+
272
+
273
+ ここで`x/f`コマンド実行。期待した値(正しいのは1.1414...)が表示されていません。
274
+
275
+ ```
276
+
277
+ (gdb) x/f $esp+4
278
+
279
+
280
+
281
+ 0x28cc0c: 3.01326646e+23
282
+
283
+ ```
284
+
285
+ `x/8xb`で8バイト分ダンプします。メモリ上の8バイトは正しいことが分かるります。
286
+
287
+ ```
288
+
289
+ (gdb) x/8xb $esp+4
290
+
291
+ 0x28cc0c: 0xcd 0x3b 0x7f 0x66 0x9e 0xa0 0xf6 0x3f
292
+
293
+ ```
294
+
295
+ 続けて`x/f`を実行。直前でサイズ指定した為にそのサイズがgdbにデフォルト値として保存されるので、正しく表示されます。
296
+
297
+ ```
298
+
299
+ (gdb) x/f $esp+4
300
+
301
+ 0x28cc0c: 1.4142135623730951
302
+
303
+ ```
304
+
305
+
306
+
307
+ おまけとして、「サイズ指定すればいいのか」と言うことで、`x/f` にサイズ指定(g=8バイト/ w=(4バイト)して実行してみます。
308
+
309
+ ```
310
+
311
+ (gdb) x/fg $esp+4
312
+
313
+ 0x28cc0c: 1.4142135623730951
314
+
315
+ (gdb) x/fw $esp+4
316
+
317
+ 0x28cc0c: 3.01326646e+23
318
+
319
+ (gdb)
320
+
321
+
322
+
323
+ ```
324
+
325
+ `x/fw`ではダメなことが分かります。