【问题标题】:Why does Clang call %eip+1 when converting double to a ulonglong?为什么 Clang 在将 double 转换为 ulonglong 时会调用 %eip+1?
【发布时间】:2012-07-28 03:16:49
【问题描述】:

结果存储在哪里?我读到它通常是 %eax,但是 64 位 uint 太宽了。我在堆栈中也找不到结果。

% clang --version
Debian clang version 3.1-3eudoxos1 (branches/release_31) (based on LLVM 3.1)
Target: i386-pc-linux-gnu
Thread model: posix

Clang 输入(已更新,签名现在对应于名称):

% cat stackoverflow.c                                  
unsigned long long double2ulonglong(double a) {
    return a;
}

编译和反汇编(已更新,添加重定位信息。现在使用 fixuns*d*fdi。):

% clang -g -Os -c stackoverflow.c && objdump -d -r stackoverflow.o
00000000 <double2ulonglong>:
   0:   83 ec 0c                sub    $0xc,%esp
   3:   f2 0f 10 44 24 10       movsd  0x10(%esp),%xmm0
   9:   f2 0f 11 04 24          movsd  %xmm0,(%esp)
   e:   e8 fc ff ff ff          call   f <double2ulonglong+0xf>
            f: R_386_PC32   __fixunsdfdi
  13:   83 c4 0c                add    $0xc,%esp
  16:   c3                      ret

主要程序(组装):

% cat main.s                                                   
.data
    a: .double 6.283045
.text
.globl main
main:
    pushl a+4
    pushl a
    call double2ulonglong
    addl $8, %esp
    ret

组装:

% as -g -o main.o -c main.s                            

链接:

% gcc -g -o executableelf stackoverflow.o main.o       

调试:

% gdb executableelf                             
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Reading symbols from /home/janus/asmplay/conv/executableelf...done.
(gdb) start
Temporary breakpoint 1 at 0x80483cc: file main.s, line 6.
Starting program: /home/janus/asmplay/conv/executableelf 

Temporary breakpoint 1, main () at main.s:6
6       pushl a+4
(gdb) list
1   .data
2       a: .double 6.283045
3   .text
4   .globl main
5   main:
6       pushl a+4
7       pushl a
8       call double2ulonglong
9       addl $8, %esp
10      ret
(gdb) break 8
Breakpoint 2 at 0x80483d8: file main.s, line 8.
(gdb) c
Continuing.

Breakpoint 2, main () at main.s:8
8       call double2ulonglong
(gdb) stepi
0x080483b4 in double2ulonglong (a=-1.9971046447753908)
(gdb) disass
Dump of assembler code for function double2ulonglong:
=> 0x080483b4 <+0>: sub    $0xc,%esp
   0x080483b7 <+3>: movsd  0x10(%esp),%xmm0
   0x080483bd <+9>: movsd  %xmm0,(%esp)
   0x080483c2 <+14>:    call   0x80483f0 <__fixunsdfdi>
   0x080483c7 <+19>:    add    $0xc,%esp
   0x080483ca <+22>:    ret    
End of assembler dump.
(gdb) break *($eip+19)
Breakpoint 3 at 0x80483c7: file stackoverflow.c, line 2.
(gdb) c
Continuing.

Breakpoint 3, 0x080483c7 in double2ulonglong (a=6.2830450000000004) at stackoverflow.c:2
2       return a;
(gdb) x/16x $esp
0xbffff374: 0x8c692f6f  0x401921d6  0xb7fb9ff4  0x080483dd
0xbffff384: 0x8c692f6f  0x401921d6  0xb7e324d3  0x00000001
0xbffff394: 0xbffff424  0xbffff42c  0xb7fdc858  0x00000000
0xbffff3a4: 0xbffff41c  0xbffff42c  0x00000000  0x0804820c
(gdb) 

编辑:修复 C 函数中的签名,链接后显示反汇编。

剩下的问题:

  • 为什么 unsigned int 6 在堆栈中不存在?
    • 答案:在 %eax 中。

【问题讨论】:

  • 我不明白。 e8 fc ff ff ff 会直接调用 fc 字节,对吧?我根本不明白这有什么意义。
  • 是的,我会这么认为。但请注意,%eip+1 只是我的解释,基于objdump 表示指令的开头位于 0xe 的事实。在gdb(链接后)中调试它时,它看起来像这样:0x080483c2 &lt;+14&gt;: call 0x80483f0 &lt;__fixunssfdi&gt;,它适合自hex(0x080483b4+0xf)=0x80483c3
  • 哦,它没有链接,好的,这里没有错
  • 但是你看到它在链接后也调用了%eip+1__fixunssfdi 是什么?
  • __fix 转换为固定的uns 无符号sf 单精度浮点数为di 64 位整数。

标签: assembly x86 clang long-integer abi


【解决方案1】:

您正在查看尚未链接的目标文件的内容,因此尚未解析外部引用。该函数可能正在调用一些编译器帮助程序,并且该调用将在链接时解决。如果将-r 开关添加到objdump,它将在调用站点打印重定位信息。

至于结果,i386 上的约定是使用 edx:eax 对返回 64 位整数。

【讨论】:

  • 在主 info registers 返回之前给我:eax=0x6 edx=0x0。我一直认为结肠的右侧是最不重要的部分,但实际上它看起来正好相反。那么 eax 是最小有效数吗?
  • 是的,eax 占据了低端。我想我应该编辑我的答案以减少混乱......
猜你喜欢
  • 1970-01-01
  • 2014-11-27
  • 1970-01-01
  • 2013-07-04
  • 1970-01-01
  • 2014-06-10
  • 1970-01-01
  • 2011-04-17
  • 2020-03-04
相关资源
最近更新 更多