rjw | 1f88458 | 2022-01-06 17:20:42 +0800 | [diff] [blame^] | 1 | On some architectures, when the kernel loads any userspace program it |
| 2 | maps an ELF DSO into that program's address space. This DSO is called |
| 3 | the vDSO and it often contains useful and highly-optimized alternatives |
| 4 | to real syscalls. |
| 5 | |
| 6 | These functions are called just like ordinary C function according to |
| 7 | your platform's ABI. Call them from a sensible context. (For example, |
| 8 | if you set CS on x86 to something strange, the vDSO functions are |
| 9 | within their rights to crash.) In addition, if you pass a bad |
| 10 | pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT. |
| 11 | |
| 12 | To find the DSO, parse the auxiliary vector passed to the program's |
| 13 | entry point. The AT_SYSINFO_EHDR entry will point to the vDSO. |
| 14 | |
| 15 | The vDSO uses symbol versioning; whenever you request a symbol from the |
| 16 | vDSO, specify the version you are expecting. |
| 17 | |
| 18 | Programs that dynamically link to glibc will use the vDSO automatically. |
| 19 | Otherwise, you can use the reference parser in |
| 20 | tools/testing/selftests/vDSO/parse_vdso.c. |
| 21 | |
| 22 | Unless otherwise noted, the set of symbols with any given version and the |
| 23 | ABI of those symbols is considered stable. It may vary across architectures, |
| 24 | though. |
| 25 | |
| 26 | (As of this writing, this ABI documentation as been confirmed for x86_64. |
| 27 | The maintainers of the other vDSO-using architectures should confirm |
| 28 | that it is correct for their architecture.) |