问题描述
当我们使用gdb
调试程序时,通常会看到在libc
(glibc
?)中定义的具有奇怪名称的函数.我的问题是:
When we debug a program using gdb
, we usually see functions with strange names defined in libc
(glibc
?). My questions are:
-
libc/glibc
是某些标准C/C ++函数(例如strcpy
,strlen
,malloc
)的标准实现吗? - 或者,不仅是如上所述的第一种用法,还是Unix/Linux系统调用(如
open
,close
,fctl
)的包装吗?如果是这样,为什么我们不能在没有libc
的情况下直接发出系统调用? -
libc
是否仅由一个lib(.a
或.so
)文件或多个lib文件组成(在这种情况下,libc
是该组lib的通用名称)?这些lib文件在哪里? -
libc
和glibc
有什么区别?
- Is
libc/glibc
the standard implementation of some standard C/C++ functions likestrcpy
,strlen
,malloc
? - Or, is it not only of the first usage as described above, but also an wrapper of Unix/Linux system calls like
open
,close
,fctl
? If so, why can't we issue syscalls directly, withoutlibc
? - Does
libc
only consist of one lib (.a
or.so
) file, or many lib files (in this case,libc
is the general name of this set of libs)? Where do these lib file(s) reside? - What is the difference between
libc
andglibc
?
推荐答案
libc
同时实现标准的C函数(例如strcpy()
)和POSIX函数(可能是系统调用)(例如getpid()
).请注意,并非所有标准C函数都在libc
中-大多数数学函数都在libm
中.
libc
implements both standard C functions like strcpy()
and POSIX functions (which may be system calls) like getpid()
. Note that not all standard C functions are in libc
- most math functions are in libm
.
您不能像调用普通函数那样直接进行系统调用,因为对内核的调用不是普通函数调用,因此链接程序无法解决它们.取而代之的是,使用特定于体系结构的汇编语言thunk来调用内核-您当然也可以直接在自己的程序中编写这些代码,但是您不必这样做,因为libc
为您提供了它们.
You cannot directly make system calls in the same way that you call normal functions because calls to the kernel aren't normal function calls, so they can't be resolved by the linker. Instead, architecture-specific assembly language thunks are used to call into the kernel - you can of course write these directly in your own program too, but you don't need to because libc
provides them for you.
请注意,在Linux中,内核和libc
的组合提供了POSIX API. libc
增加了可观的价值-并非每个POSIX函数都必须是系统调用,对于那些POSIX函数来说,内核行为并不总是与POSIX保持一致.
Note that in Linux it is the combination of the kernel and libc
that provides the POSIX API. libc
adds a decent amount of value - not every POSIX function is necessarily a system call, and for the ones that are, the kernel behaviour isn't always POSIX conforming.
libc
是单个库文件(.so
和.a
版本均可用),并且在大多数情况下位于/usr/lib
中.但是,glibc(GNU libc)项目提供的不仅是libc
-它还提供了前面提到的libm
和其他核心库,例如libpthread
.因此,libc
只是glibc提供的库之一-除glibc之外,还有libc
的其他替代实现.
libc
is a single library file (both .so
and .a
versions are available) and in most cases resides in /usr/lib
. However, the glibc (GNU libc) project provides more than just libc
- it also provides the libm
mentioned earlier, and other core libraries like libpthread
. So libc
is just one of the libraries provided by glibc - and there are other alternate implementations of libc
other than glibc.
这篇关于libc(glibc)在我们的Linux应用程序中起什么作用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!