进程挂住问题

_nosay

回复 28# nswcfd




   

sky__sea

跟了一下，发现问题出在
write(3, "\1\0\0\0\1", 5)               = 4294967264
--- SIGPIPE (Broken pipe) @ 0 (0) ---

这一步，好奇怪，4294967264正好是EPIPE的值，而后面确实是收到的SIGPIPE信号，为什么write的返回值变成了errno的值？

nswcfd

write syscall的错误返回值就是-errno，只是libc会再封装一层，按照POSIX标准，把错误值存到errno，把write库函数的返回值定义为-1

nswcfd

int f() { return -1; }
long l = f();

1）由于f声明为int，所以返回值-1通过eax返回。注意这时候如果观察rax，会发现它的值是2^32-1，而不是2^64-1（即高32位为0）。
2）对long赋值的时候，会调用cltq，对eax进行符号扩展（按照c标准整形提升的语义，把32位的-1转为64位的-1），所以long的值是-1l，而不是很大的整数。

在楼主的例子里，实际上存在两份声明（一份是有问题的kernel实现，一份在libc的头文件里），可以简化为在两个文件里声明。

file1:
int f() { return -1; } //内核里的错误实现

file2:
long f();  //标准库声明为long
long l = f();

对于file2，由于引用的是标准库的原型声明，所以对long l的赋值，编译器不会产生cltq（提升操作），才会导致l变成一个很大的整数（原因见解释1）

sky__sea

没有太明白，我是不是可以这么理解，应用层调用的是libc封装的f函数，而我的内核f函数是在libc的封装函数里面被调用，那么在封装函数里面调用我的f函数的时候，应该也是赋值给一个long变量吧，那岂不是符合你说的第2条，对eax进行符号扩展然后赋值给了那个变量吗，结果不应该还是-1吗？

nswcfd

这个模型跟内核/非内核没有关系，用两个独立编译单元（file1/file2）同样可以验证。

（2）是在解释，为什么 long l = int_f() 的值是-1（经过cltq的转换）而不是很大的值。
“对long赋值的时候”，严格说来是“【int】对long赋值的时候”，而不是“【long】对long赋值的时候”。

正是由于标准库的存在，编译器理解f的返回值为long，而不是int，所以就没有（2）。

这里的关键是，用户态程序在编译的时候，根本就不看内核源码树下的头文件。
同样的，file2编译的过程，不关心file1的存在，也就没有int赋值long的过程，自然就没有cltq。

sky__sea

nswcfd兄弟好像对汇编很熟悉啊，真是佩服，我一点都不熟悉，但是我发现懂汇编对理解和解决很多问题都有很大的帮助。