ldd问题

[geodge831012]

ldd一个可执行程序得到的 依赖共享库后面的地址 是 进程空间里加载这些共享库的地址吗？

linux 32位 radhat 4u4
编译一个简单的hello world的c程序，ldd它的可执行文件，
libc.so.6 => /lib/tls/libc.so.6 (0x00318000)

freebsd 64位（手头上没32位的bsd机器）
ldd同样的一个可执行程序
libc.so.6 => /lib/libc.so.6 (0x800633000)

按照“深入理解计算机系统”第十章的描述
进程空间的共享内存是存放是从0x40000000开始的
0x800633000感觉有点偏得太多了
而0x00318000更是处于0x08048000（代码段起始位置）以前的禁用空间

我的感觉是“深入理解计算机系统”说的是一种概念，具体各个系统的实现都会有所不同
比如linux64位的话，libc.so.6 => /lib64/tls/libc.so.6 (0x0000003e26800000)
不知道我这样想对不对？

[独孤过儿]

这些地址都是逻辑地址，不是真正的地址

你直接用 readelf -h fileName 查看一个可执行程序，能看到有个入口地址，那个就是程序实际开始运行的逻

辑地址，而ldd显示出来的结果，也都是和这个一样，都是逻辑地址

当程序加载到内存中开始运行以后，OS的内存管理部分将逻辑地址经过段页转换，变成实际的物理地址，寻址

到实际指令或者数据所在的物理地址。

深入理解计算机系统 只是说了一种很理论上的情况，但是实际实现的过程中，很可能有不同，就像UNIX和现

在的某些linux，readelf看到的入口地址都不一样。所以看书是一方面，自己实际动手去试验去总结是另一方面

[geodge831012]

[Quote=引用 1 楼 fetag 的回复:]
这些地址都是逻辑地址，不是真正的地址

你直接用 readelf -h fileName 查看一个可执行程序，能看到有个入口地址，那个就是程序实际开始运行的逻

辑地址，而ldd显示出来的结果，也都是和这个一样，都是逻辑地址

当程序加载到内存中开始运行以后，OS的内存管理部分将逻辑地址经过段页转换，变成实际的物理地址，寻址

到实际指令或者数据所在的物理地址。

深入理解计算机系统 只是说了一种很理论上的情况，但是实际实现的过程中，很可能有不同，就像UNIX和现

在的某些linux，readelf看到的入口地址都不一样。所以看书是一方面，自己实际动手去试验去总结是另一方面
[/Quote]
对啊，我说的这个地址当然是每个进程自己的进程空间啊。
我的意思是说就是在这个4GB（32位系统）的虚拟空间上，0x08048000之前的部分是禁用的，但是在这个系统上共享库却用了，这是不是说明每个系统都有自己对进程空间结构的理解，而不是遵循某一个固定的格式。

[geodge831012]

[Quote=引用 3 楼 fetag 的回复:]
我以前看过一篇文章，介绍0x08048000这个魔数的由来，你可以搜一下

那里面我记得介绍了为什么内存管理要这么做
[/Quote]
非常感谢

[独孤过儿]

我以前看过一篇文章，介绍0x08048000这个魔数的由来，你可以搜一下

那里面我记得介绍了为什么内存管理要这么做