glibc

How to intercept file system access inside dlopen()?

♀尐吖头ヾ 提交于 2019-12-06 01:49:58
问题 I want to intercept all file system access that occurs inside of dlopen(). At first, it would seem like LD_PRELOAD or -Wl,-wrap, would be viable solutions, but I have had trouble making them work due to some technical reasons: ld.so has already mapped its own symbols by the time LD_PRELOAD is processed. It's not critical for me to intercept the initial loading, but the _dl_* worker functions are resolved at this time, so future calls go through them. I think LD_PRELOAD is too late. Somehow

对malloc和free的思考

我们两清 提交于 2019-12-05 20:54:26
进程的内存布局: Heap的顶端的限制叫做program break,通过系统调用brk活着sbrk可以想内核申请内存从而改变break,也就是增加或收缩heap的大小。 进程的地址空间所面对的都是虚拟地址,kernel为每个进程维护一个page table,建立了虚拟地址空间的页和物理内存页或swap空间的映射(虚拟内存或物理内存都是以页为单位)。 很重要的一个特点是,虚拟地址空间是连续的! 虚拟内存管理有很多好处:1、进程相互之间或进程与内核之间相互隔离,进程不能操作其他进程的内存空间,更不能操作内核的空间。2、多个进程可以共享内存。 (多个进程执行相同的程序,也就是多个进程的text segment所对应的物理内存是同一份),节约内存。3、进程维护的页表可以更容易的实现内存保护。(标记page table的entry即可) 虚拟内存这块让我想到了,“软件的很多问题都可以靠加一个中间层解决”;o(∩_∩)o 哈哈 下面是一个简单的malloc和free实现,通过系统调用sbrk来实现: 实现细节: 1、在需要的内存块前面追加一小块空间,来存储当前块的大小(貌似都这样) 2、维护两个全局变量,managed_memory_start、所维护内存的起始地址 last_valid_address、所维护内存的最后有效地址,也就是program break 3、free的实现很简单

查看当前系统的glibc版本

孤者浪人 提交于 2019-12-05 20:54:13
有时我们经常需要查看当前系统的glibc版本,可以这样查看: /lib/libc.so.6 有时:/lib/x86-64-linux/libc.so.6 把这个文件当命令执行一下 为什么这个库可以直接run呢? 原来在libc的代码中有一点小手脚: Makerules:586:LDFLAGS-c.so += -e __libc_main csu/version.c:71:__libc_main (void) void __libc_main (void) { __libc_print_version (); _exit (0); } 或者: 因为ldd命令也是glibc提供的,所以也能查看 ldd --version glibc是什么,以及与gcc的关系? glibc是gnu发布的libc库,也即c运行库。glibc是linux 系统中最底层的api(应用程序开发接口),几乎其它任何的运行库都会倚赖于glibc。glibc除了封装linux操作系统所提供的系统服务外,它本 身也提供了许多其它一些必要功能服务的实现,主要的如下: (1)string,字符串处理 (2)signal,信号处理 (3)dlfcn,管理共享库的动态加载 (4)direct,文件目录操作 (5)elf,共享库的动态加载器,也即interpreter (6)iconv,不同字符集的编码转换 (7)inet

Why glibc binary is called libc.so.6 not a libc.so.1 or libc.so.4?

喜你入骨 提交于 2019-12-05 20:36:08
问题 The modern glibc binary is called libc.so.6 in Linux. Why is "6" used here? The libc.so.1 or libc.so.8 can be good names too IMHO. Wikipedia gives some history at http://en.wikipedia.org/wiki/GNU_C_Library but doesn't explain fully In the early 1990s, the developers of the Linux kernel forked glibc. Their fork, called "Linux libc", was maintained separately for years and released versions 2 through 5. When FSF released glibc 2.0 in January 1997, .... At this point, the Linux kernel developers

Debugging the C runtime

我怕爱的太早我们不能终老 提交于 2019-12-05 19:28:01
I want to get a detailed look at what's going on both before and after main() using GDB. Would it be enough just to recompile glibc with -g and link against that? if you want to play with the debugger, you can use GDB this way: install the debug-info for the `glibc` package ( here is the way to do it with Fedora, I don't know about the other distros) or point GDB to a consistent debug file directory: (gdb) show debug-file-directory The directory where separate debug symbols are searched for is "/usr/lib/debug". (gdb) set debug-file-directory ... (it's /usr/lib/debug/lib64/libc-2.14.so.debug in

GLIBCXX_3.4.15, GLIBC_2.15 and GLIBC_2.14 not found - Centos 6.5

…衆ロ難τιáo~ 提交于 2019-12-05 19:26:47
I am trying to run an app but I get ... /usr/lib64/libstdc++.so.6: VERSION 'GLIBCXX_3.4.15' not found /lib64/libc.so.6: VERSION 'GLIBC_2.15' not found /lib64/libc.so.6: VERSION 'GLIBC_2.14' not found ... When I do "strings /usr/lib64/libstdc++.so.6 | grep GLIBC" i get a normal list... ... GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 ... GLIBCXX_3.4.13 GLIBCXX_2.2.5 GLIBCXX_2.3.2 ... I don't seem to find a simple tutorial on how to install the missing libs/files/dependencies, (or Centos 6.5 or anything else for that mater). Can someone explain how to install whatever might be missing

Is mmap a built in function?

心已入冬 提交于 2019-12-05 18:40:55
I know that mmap is a system call, but there must be some wrapper in glibc that does the system call. Yet when I try to use gdb to step through the mmap function in my program, gdb ignores it as it can't find any source file for it (Note I compile my own glibc from source). I can step through other glibc library functions such as printf and malloc but not mmap . I also use the flag -fno-builtin so that gcc doesn't use built in functions. Any help on this will be greatly appreciated. I don't know what your problem is. It works perfectly fine for me. Using system libc.so.6 , with debug symbols

PHP ICONV glibc to libiconv on CentOS 5.5

醉酒当歌 提交于 2019-12-05 18:32:56
I'm having a few issues with the PHP function iconv, which I've tracked down the the iconv implementation. As the manual states, "Note that the iconv function on some systems may not work as you expect. In such case, it'd be a good idea to install the GNU libiconv library." http://uk3.php.net/manual/en/intro.iconv.php I've downloaded the libiconv library from http://www.gnu.org/software/libiconv/ and installed it without any problems using: $ ./configure --prefix=/usr/local $ make $ make install My problem now is how to link this installation to PHP? From what i've read I need to recompile PHP

malloc分配到一块内存,读写操作时却发生segmentation falt的奇怪问题。

跟風遠走 提交于 2019-12-05 18:19:06
期初现象:malloc一块内存,读写操作时发生segmentation falt。一般来讲malloc倘若失败应该抛出异常,所以malloc返回一个指针后,这个指针应该都是可用的,况且是进行读操作。 所以遇到这个问题时感觉很奇怪。 继续现象:经过地址打印确认该地址是前面操作过的一个地址。说明地址不在系统保护区。 继续现象:通过地址便宜发现该地址前面便宜几位就能够访问了,说明仅有该段内存出了问题。怀疑该段内存被某些代码做了手脚。 重现现象:安卓上munmap大于1835008后面再用这块内存就会core。 测试代码: { int test_size = 1835008; std::cout<<"test_size:"<<test_size<<std::endl; char * abc = (char *)malloc(test_size); abc[1] = 'a'; std::cout<<(long long)abc<<std::endl; std::cout<<abc[1]<<std::endl; std::cout<<munmap(abc test_size)<<std::endl; std::cout<<abc[1]<<std::endl; free(abc); abc = (char *)malloc(test_size); std::cout<<(long long

Can GHC link binaries against a libc implementation such as uclibc (used in OpenWrt by default)?

ε祈祈猫儿з 提交于 2019-12-05 17:59:21
问题 I am using Debian/MIPS+QEMU to build MIPS ports of PortFusion (a TCP tunneling solution). The resulting binaries are linked against GNU libc. Thus, they cannot be just copied over and used on vanilla OpenWrt which ships with uclibc instead of eglibc (which seems binary-compatible with GNU libc). Is there a way to link Haskell/GHC binaries on Debian/MIPS against uclibc instead of eglibc ? Can OpenWrt's using uclibc be really the reason why PortFusion binaries copied over from Debian fail to