关于动态库的问题

2004-10-12 04:26:36 297 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

cygwin中动态库链接的问题问题的出现 (这里解释得比较累赘, 要找到答案, 可以直接进入第二章节) 看书(Ruminations on C++)时, 以章节为单位写了一些独立的小程序(使用cygwin g++作为编译器, sublime text 2作为编辑器). 以下是目录结构, 后来将写日志的函数提取出来, 放到common/common.h(.cpp), 并生成libcommon.so动态库, 供其他程序调用阅读详情

有哪位大侠知道如何获得动态库载入内存时的起始地址及大小??
动态库是保存在堆?栈?or 堆栈之间?

...全文

c++ 动态库虚表问题导致的不兼容问题实例 c++动态库在abi兼容方面臭名昭著，这里结合一个线上模块使用动态库导致出core的问题总结下动态库、虚函数表等知识，这里将线上遇到的问题抽象出一个极简的例子，三个文件include.h, main.cpp, func.cpp ，先上源码 include.h: class Base { public: void virtual func1() = 0; }; class Wrapper { public: Base *b; }; extern void jj(Wrapper *); 阅读详情

lysliberty

Linux/Unix社区 23,224 成员 74,535 内容

+ 关注 + 加入社区

切换为时间正序

CoolQ 2004-10-14

打赏
举报

上边的maps包含的内容很多，不是几句话就能讲明白的。

CoolQ 2004-10-14

打赏
举报

#cat /proc/1755/exec
lrwxrwxrwx 1 root root 0 Oct 13 22:52 exe -> /bin/bas
#cat /proc/1755/maps
00111000-0011b000 r-xp 00000000 08:02 79616 /lib/libnss_files-2.3.3.so
0011b000-0011c000 r--p 00009000 08:02 79616 /lib/libnss_files-2.3.3.so
0011c000-0011d000 rw-p 0000a000 08:02 79616 /lib/libnss_files-2.3.3.so
00908000-0091d000 r-xp 00000000 08:02 83601 /lib/ld-2.3.3.so
0091d000-0091e000 r--p 00014000 08:02 83601 /lib/ld-2.3.3.so
0091e000-0091f000 rw-p 00015000 08:02 83601 /lib/ld-2.3.3.so
00921000-00a36000 r-xp 00000000 08:02 83602 /lib/tls/libc-2.3.3.so
00a36000-00a38000 r--p 00115000 08:02 83602 /lib/tls/libc-2.3.3.so
00a38000-00a3a000 rw-p 00117000 08:02 83602 /lib/tls/libc-2.3.3.so
00a3a000-00a3c000 rw-p 00000000 00:00 0
00a3e000-00a40000 r-xp 00000000 08:02 83607 /lib/libdl-2.3.3.so
00a40000-00a41000 r--p 00001000 08:02 83607 /lib/libdl-2.3.3.so
00a41000-00a42000 rw-p 00002000 08:02 83607 /lib/libdl-2.3.3.so
00ac7000-00aca000 r-xp 00000000 08:02 83609 /lib/libtermcap.so.2.0.8
00aca000-00acb000 rw-p 00002000 08:02 83609 /lib/libtermcap.so.2.0.8
00d37000-00d38000 r-xp 00000000 00:00 0
08047000-080d2000 r-xp 00000000 08:02 284585 /bin/bash
080d2000-080d8000 rw-p 0008b000 08:02 284585 /bin/bash
080d8000-080dc000 rw-p 00000000 00:00 0
09eff000-09f20000 rw-p 00000000 00:00 0
f6e31000-f6e32000 rw-p 00000000 00:00 0
f6e33000-f6e34000 rw-p 00000000 00:00 0
f6e34000-f6e3a000 r--s 00000000 08:02 79853 /usr/lib/gconv/gconv-modules.cache
f6e3a000-f703a000 r--p 00000000 08:02 67181 /usr/lib/locale/locale-archive
f7044000-f7046000 rw-p fffff000 00:00 0
fee75000-ff000000 rw-p fff6f000 00:00 0
ffffd000-ffffe000 ---p 00000000 00:00 0
以上是Redhat FC2的结果，内核是2.6.5，Redhat自己打了4G／4G的内核补丁，还有为了防止ret-libc攻击打了动态链接的补丁。你要是真想深入研究，不该在这里问。有条件还是自己看源代码吧

lysliberty 2004-10-14

打赏
举报

ok! 顶再!

lysliberty 2004-10-14

打赏
举报

还有，如果在动态库分配内存，那这块内存应该在哪里分配？

lysliberty 2004-10-14

打赏
举报

ding!

winux0 2004-10-13

打赏
举报

用ldd可以看到动态连接库的加载情况

tkit 2004-10-13

打赏
举报

动态库并不是在分配在堆上，只不过位置在堆的后面：
|用户程序|堆|动态库loader|动态库|栈
通常用户程序和动态库的起始地址是固定的，但是特定于实现，所以不用拘泥于具体的数值。

在linux中，一个进程的堆被定义为程序数据段开始data_start到data_start+limitation. 这个limitation可以通过“ulimit -d"来设置。当用户通过brk来扩大当前堆的时候，内核会检查这次扩大是否会破坏已经存在的vma，如果是，则会放弃这次操作。这个特性决定了堆最大就是动态库ld的起始-程序数据段的起始。看官不用担心，并不是说动态库以后的大片区域就不能被使用，通常程序会通过malloc来实现内存分配，glibc的malloc实现了几种策略，既可以从堆中获取，也可以通过mmap来映射进程地址空间任何一块区域（当然是栈顶以下，3G以内哈）。LD_PRELOAD不过是允许用户自己实现的库来替代标准的glibc的动态库，有种说法是叫interpolater。至于加载位置由库的加载顺序和loader来决定，随机的

lysliberty 2004-10-13

打赏
举报

自己顶

lysliberty 2004-10-13

打赏
举报

我的进程的maps如下:
08048000-0804b000 r-xp 00000000 03:07 528452 /home/myckpt/client
0804b000-0804c000 rw-p 00003000 03:07 528452 /home/myckpt/client
0804c000-0804d000 rwxp 00000000 00:00 0
40000000-40015000 r-xp 00000000 03:05 600290 /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:05 600290 /lib/ld-2.3.2.so
40016000-40017000 rw-p 00000000 00:00 0
40017000-40024000 r-xp 00000000 03:07 512361 /home/librocks.so.1.0.0
40024000-40026000 rw-p 0000d000 03:07 512361 /home/librocks.so.1.0.0
40026000-40040000 rw-p 00000000 00:00 0

从上面的maps来看,我同意tkit(熊熊520)的观点.
也就是说程序内存的分布是|用户程序|堆|动态库loader|动态库|栈.

请问CoolQ()兄,你觉得问题在哪里?

CoolQ 2004-10-13

打赏
举报

lysliberty 2004-10-12

打赏
举报

to winux0(阿鱼木木): 这就是说动态库不是加载到代码段,而是在堆的上面, 对吧?

to CoolQ(): 老兄, 有什么函数可以直接得到某个动态库在内存中的起始地址?
难道只能通过读maps这个笨办法吗?
还有,LD_PRELOAD 对动态库的加载位置有什么影响?

呵呵,问题比较多,谢拉!

winux0 2004-10-12

打赏
举报

写错了，程序都是从0x08048000开始运行

winux0 2004-10-12

打赏
举报

所有的程序都是从0x0848000开始运行，而所用到的动态连接库都是从0x040000000开始加载

CoolQ 2004-10-12

打赏
举报

cat /proc/$pid/maps
or refer to ld source code

lysliberty 2004-10-12

打赏
举报

to pacman2000(pacman)(影子传说) :
这个我倒是知道,但是我用sbrk(0)看了一下我堆顶的地址,结果是0x804d000.
而在/proc/本进程id/maps中却发现动态库的加载起始地址是:0x40017000
这说明动态库是加载到堆的上面,也就是说动态库没有加载到text段中.
这是为什么?

pacman2000 2004-10-12

打赏
举报

动态库是代码段。。。而且代码是多个程序公用的。
装载进去的起始地址不固定，因此编译动态库的时候要用-fPIC编译成位置无关的代码。

gordenfl 2004-10-12

打赏
举报

动态链接库保存代码段里面的,当然是在栈里面的!

关于动态库的问题

相关推荐