98eedc3a9d
It turns out that parsing the vDSO is nontrivial if you don't already have an ELF dynamic loader around. So document it in Documentation/ABI and add a reference CC0-licenced parser. This code is dedicated to Go issue 1933: http://code.google.com/p/go/issues/detail?id=1933 Signed-off-by: Andy Lutomirski <luto@mit.edu> Link: http://lkml.kernel.org/r/a315a9514cd71bcf29436cc31e35aada21a5ff21.1310563276.git.luto@mit.edu Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
27 lines
No EOL
1.3 KiB
Text
27 lines
No EOL
1.3 KiB
Text
On some architectures, when the kernel loads any userspace program it
|
|
maps an ELF DSO into that program's address space. This DSO is called
|
|
the vDSO and it often contains useful and highly-optimized alternatives
|
|
to real syscalls.
|
|
|
|
These functions are called just like ordinary C function according to
|
|
your platform's ABI. Call them from a sensible context. (For example,
|
|
if you set CS on x86 to something strange, the vDSO functions are
|
|
within their rights to crash.) In addition, if you pass a bad
|
|
pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT.
|
|
|
|
To find the DSO, parse the auxiliary vector passed to the program's
|
|
entry point. The AT_SYSINFO_EHDR entry will point to the vDSO.
|
|
|
|
The vDSO uses symbol versioning; whenever you request a symbol from the
|
|
vDSO, specify the version you are expecting.
|
|
|
|
Programs that dynamically link to glibc will use the vDSO automatically.
|
|
Otherwise, you can use the reference parser in Documentation/vDSO/parse_vdso.c.
|
|
|
|
Unless otherwise noted, the set of symbols with any given version and the
|
|
ABI of those symbols is considered stable. It may vary across architectures,
|
|
though.
|
|
|
|
(As of this writing, this ABI documentation as been confirmed for x86_64.
|
|
The maintainers of the other vDSO-using architectures should confirm
|
|
that it is correct for their architecture.) |