/proc/kallsysms содержит символы динамически загружаемых модулей и статический код, а system.map - таблицы символов только статического кода
Это всё - Букварь, это общеизвестно и неинтересно.
Но это ещё и не всё: адрес одного и того же имени в /proc/kallsysms и system.map - различаются, все на одно и то же смещение.
Но интересно именно:
Как включается-выключается этот механизм смещения?
Когда (с какого ядра) он появляется (или дефаултно используется)?
Как, каким механизмом, адреса имён в модулях (абсолютные адреса) связываются со смещёнными адресами /proc/kallsyms?
Пользователь добавил сообщение 31 Октября 2019, 21:02:06:
адрес одного и того же имени в /proc/kallsysms и system.map - различаются, все на одно и то же смещение.
Вот этот механизм, случайного смещения, ASLR (address space layout randomization), включается конфигурационным параметром ядра CONFIG_RANDOMIZE_BASE:
olej@ACER:~/2019_WORK/ACCOUNTS/MAIL$ cat /boot/config-`uname -r` | grep CONFIG_RANDOMIZE_BASE
CONFIG_RANDOMIZE_BASE=y
Пользователь добавил сообщение 31 Октября 2019, 21:50:39:
Как, каким механизмом, адреса имён в модулях (абсолютные адреса) связываются со смещёнными адресами /proc/kallsyms?
Всё, с этим тоже ясно, вопрос снят. Если кому пригодится:
- это модуль ядра (мой собственный, какой не имеет значения):
olej@ACER:~/2019_WORK/own.WORK/KPI/dev/cdev$ nm -n fixdev.ko
U alloc_chrdev_region
U cdev_add
U cdev_del
U cdev_init
U _copy_to_user
U __fentry__
U param_ops_int
U printk
U register_chrdev_region
U __stack_chk_fail
U unregister_chrdev_region
U __warn_printk
0000000000000000 T cleanup_module
0000000000000000 t copy_overflow
...
- по формату это - объектиный файл, а имена связываемые с символами ядра отмечены как U(UNDEFINED - эти адреса связываются при insmod):
olej@ACER:~/2019_WORK/own.WORK/KPI/dev/cdev$ sudo cat /proc/kallsyms | grep ' T ' | grep cdev_
ffffffff81867860 T cdev_set_parent
ffffffff81867910 T cdev_add
ffffffff81867960 T cdev_del
ffffffff818679c0 T cdev_device_add
ffffffff81867a30 T cdev_device_del
ffffffff81867a60 T cdev_init
ffffffff81867ae0 T cdev_alloc
ffffffff81868220 T cdev_put
ffffffff81b8f1e0 T thermal_cdev_update