移植64位发生的问题（跟cltq指令有关）

Posted 2022-12-01 爱搬砖的摄影师

原文地址：http://filwmm1314.blog.163.com/blog/static/218259192012102424024131/

同事昨天在群里问了一个问题，大概将一个32位机器上运行良好的程序，移植到64位机器上之后出现了问题，看了一下core，大概是一个返回指针的函数，在函数内查看返回值还是正确的，但是到调用函数里面，返回值却被截掉了一段，引起了core。

具体代码如下： char *attach_shm(char *shmstr, int defaultkey, int shmsize)     char *shmptr;     int shmkey, shmid;     shmkey = search_shmkey(shmstr);     if (shmkey < 1024)         shmkey = defaultkey;     shmid = shmget(shmkey, shmsize, 0);     if (shmid < 0)     ........
    else     ........         return shmptr; attach_shm实现很简单，分配一块共享内存，然后返回内存的（首）地址。
调用处的代码：    char * myTmp =          attach_shm(shmkey, 5000 + mode * 10,                             sizeof(struct FILESHM) * maxnum);
有一点要提的是：调用attach_shm和定义attach_shm的不是同一个源文件。（后面会知道，这也是产生问题的原因之一） 这里的问题是，在使用GDB跟踪的时候打印shmptr出来看还是一个64位的值，但是函数返回之后打印myTmp的值确实32位的，这肯定要引起core啊。 可是问题是，这里上下文也不存储缓冲区溢出之类的可能，为什么返回值会被截掉一段呢？ 使用GDB跟踪了一下，发现，在attach_shm里面，返回值去%rax的值还是正确的，可是到返回之后%rax的值却变了。这下更郁闷了，难道还有什么东西改变了%rax的值？以我浅薄的知识理解，都是没有这种可能的啊。 实在没办法了，只要将这两个函数反编译出来看看汇编代码了，在调用attach_shm的地方发现了一下代码：   43063f:       48 89 ca                mov    %rcx,%rdx   430642:       48 89 c7                mov    %rax,%rdi   430645:       b8 00 00 00 00          mov    $0x0,%eax   43064a:       e8 00 c3 fe ff          callq  41c94f <attach_shm>   43064f:       48 98                    cltq   430651:       48 89 85 00 ff ff ff    mov    %rax,-0x100(%rbp)   430658:       48 8b 85 00 ff ff ff    mov    -0x100(%rbp),%rax 注意被标注红色的cltq指令，在函数返回之后为什么会有这个指令？怎么其他函数调用之后没看到这个呢？这条指令我之前没接触过，不知道是干什么用的，于是google了一把，就发现早就有人踩过这个cltq这个坑了。
具体链接在  这里 ，这里说的很详细，我就不太多解释了。不明白cltq指令的意思的同学，可以看文章里面那个pdf 文档。
简单来说就是attach_shm这个函数在调用函数编译的时候没有声明过，于是编译器便将这个函数的返回值默认为32位，这个在32位机器上不会有什么问题，因为在32位机器上指针的长度也是32位，但在64位机器上，指针的长度是64位，默认32位的话，就有问题了。这也就是返回值被截断的原因了。 解决的方法很简单，使用头文件声明一下attach_shm这个函数，再让调用该函数的地方包含该头文件就行了。 整个解决问题的过程给我的感觉就是，懂一点汇编，或者说看的懂汇编，对于调试还是挺有帮助的。