On Wed, Jul 10, 2024 at 10:53:11AM +0200, Alexander Gordeev wrote: > On Tue, Jul 09, 2024 at 09:21:41PM +0200, Petr Tesařík wrote: > > Hi Petr, > ... > > > I would say to some degree there is also inconsisten with regard > > > to /proc/ files existence: > > > /proc/kcore is enabled by CONFIG_PROC_KCORE option, while > > > /proc/kallsyms is enabled by CONFIG_KALLSYMS option. > > > I assume drgn expects both files exist and does not work otherwise. > > > > > > Nevertheless, it is still possible to refer to only one file for > > > symbol resolution and use an always-present symbol. E.g _stext > > > could be leveraged like this: > > > > > > # grep -w init_task /proc/kallsyms > > > 000003ffe13e9400 D init_task > > > # grep -w _stext /proc/kallsyms > > > 000003ffe0000000 T _stext > > > > > > 0x3ffe13e9400 - 0x3ffe0000000 == 0x13e9400 > > > > > > # eu-readelf -s vmlinux | grep -w _stext > > > 178112: 0000000000100000 0 NOTYPE GLOBAL DEFAULT 1 _stext > > > > > > 0x13e9400 + 0x100000 == 0x14e9400 > > > > > > # eu-readelf -s vmlinux | grep -w init_task > > > 498: 0000000000000000 0 FILE LOCAL DEFAULT ABS init_task.c > > > 182344: 00000000014e9400 8960 OBJECT GLOBAL DEFAULT 28 init_task > > > > > > I guess, the above holds true for all architectures. > > > If so, I would suggest consider using that approach. > > > > > > Having said that, we will try to turn KERNELOFFSET from a synthetic > > > value "Used to compute the page offset" to what drgn expects it to be. > > > > Thinking about it now, I'm not sure it makes life easier. Because then > > we'll have some old kernels with the current (unexpected) definition of > > KERNELOFFSET and some new kernels with a more standard definition of > > it, but if I read vmcoreinfo, how do I know if the value has the old or > > the new meaning? > > The approach I suggested to consider would not use KERNELOFFSET at all. Hi, Unfortunately, using kallsyms isn't feasible for a few reasons: 1) /proc/kallsyms is not available when debugging a core dump. 2) As you pointed out, /proc/kallsyms is not necessarily enabled together with /proc/kcore. 3) Reading /proc/kallsyms is slow. On my system, drgn starts up in about 250ms, and reading /proc/kallsyms takes about 110 ms. This would slow down startup too much. drgn intentionally avoids kallsyms for these reasons. (There is one corner case on old < 4.11 kernels where we need kallsyms, but that will go away eventually.) I'd be really grateful if KERNELOFFSET was always the difference between addresses in the kernel image and in memory like it is on other architectures, or even if there was another, s390x-specific field in vmcoreinfo for that. Thanks, Omar
