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. > Petr T Thanks!
