kernel/linux.git/scripts/gdb/linux/symbols.py, branch v6.6.132

revert "scripts/gdb/symbols: add specific ko module load command"

2023-09-19T20:21:33+00:00

Revert 11f956538c07 ("scripts/gdb/symbols: add specific ko module load command") due to breakage identified by Johannes Berg in [1]. Fixes: 11f956538c07 ("scripts/gdb/symbols: add specific ko module load command") Reported-by: Johannes Berg Closes: https://lkml.kernel.org/r/c44b748307a074d0c250002cdcfe209b8cce93c9.camel@sipsolutions.net [1] Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Jan Kiszka Cc: Kieran Bingham Cc: Kuan-Ying Lee Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb/symbols: add specific ko module load command

2023-08-21T20:46:21+00:00

Patch series "Add GDB memory helper commands", v2. I've created some GDB commands I think useful when I debug some memory issues and kernel module issue. For memory issue, we would like to get slabinfo, slabtrace, page_owner and vmallocinfo to debug the memory issues. For module issue, we would like to query kernel module name when we get a module text address and load module symbol by specific path. Patch 1-2: - Add kernel module related command. Patch 3-5: - Prepares for the memory-related command. Patch 6-8: - Add memory-related commands. This patch (of 8): Add lx-symbols command to support add specific ko module. Example output like below: (gdb) lx-symbols mm/kasan/kasan_test.ko loading @0xffff800002d30000: mm/kasan/kasan_test.ko Link: https://lkml.kernel.org/r/20230808083020.22254-1-Kuan-Ying.Lee@mediatek.com Link: https://lkml.kernel.org/r/20230808083020.22254-2-Kuan-Ying.Lee@mediatek.com Signed-off-by: Kuan-Ying Lee Cc: AngeloGioacchino Del Regno Cc: Chinwen Chang Cc: Matthias Brugger Cc: Qun-Wei Lin Signed-off-by: Andrew Morton

scripts/gdb: fix lx-symbols command for arm64 LLVM

2023-08-18T17:18:58+00:00

lx-symbols assumes that module's .text sections is located at `module->mem[MOD_TEXT].base` and passes it to add-symbol-file command. However, .text section follows after .plt section in modules built by LLVM toolchain for arm64 target. Symbol addresses are skewed in GDB. Fix this issue by using the address of .text section stored in `module->sect_attrs`. Link: https://lkml.kernel.org/r/20230801121052.2475183-1-koudai@google.com Signed-off-by: Koudai Iwahori Cc: Jan Kiszka Cc: Kieran Bingham Signed-off-by: Andrew Morton

scripts/gdb: use mem instead of core_layout to get the module address

2023-04-13T21:03:25+00:00

commit ac3b43283923 ("module: replace module_layout with module_memory") changed the struct module data structure from module_layout to module_memory. The core_layout member which is used while loading modules are not available anymore leading to the following error while running gdb: (gdb) lx-symbols loading vmlinux Python Exception : There is no member named core_layout. Error occurred in Python: There is no member named core_layout. Replace core_layout with its new counterpart mem[MOD_TEXT]. Fixes: ac3b43283923 ("module: replace module_layout with module_memory") Signed-off-by: Pankaj Raghav Signed-off-by: Luis Chamberlain

scripts/gdb: Fix gdb 'lx-symbols' command

2022-07-21T17:40:55+00:00

Currently the command 'lx-symbols' in gdb exits with the error`Function "do_init_module" not defined in "kernel/module.c"`. This occurs because the file kernel/module.c was moved to kernel/module/main.c. Fix this breakage by changing the path to "kernel/module/main.c" in LoadModuleBreakpoint. Signed-off-by: Khalid Masum Acked-by: Luis Chamberlain Fixes: cfc1d277891e ("module: Move all into module/") Reviewed-by: Douglas Anderson Signed-off-by: Linus Torvalds

scripts/gdb: handle split debug for vmlinux

2021-11-09T18:02:52+00:00

This is related to two previous changes. Commit dfe4529ee4d3 ("scripts/gdb: find vmlinux where it was before") and commit da036ae14762 ("scripts/gdb: handle split debug"). Although Chrome OS has been using the debug suffix for modules for a while, it has just recently started using it for vmlinux as well. That means we've now got to improve the detection of "vmlinux" to also handle that it might end with ".debug". Link: https://lkml.kernel.org/r/20211028151120.v2.1.Ie6bd5a232f770acd8c9ffae487a02170bad3e963@changeid Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Cc: Jan Kiszka Cc: Kieran Bingham Cc: Johannes Berg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

gdb: lx-symbols: store the abspath()

2021-05-07T07:26:32+00:00

If we store the relative path, the user might later cd to a different directory, and that would break the automatic symbol resolving that happens when a module is loaded into the target kernel. Fix this by storing the abspath() of each path given, just like we already do for the cwd (os.getcwd() is absolute.) Link: https://lkml.kernel.org/r/20201217091747.bf4332cf2b35.I10ebbdb7e9b80ab1a5cddebf53d073be8232d656@changeid Signed-off-by: Johannes Berg Reviewed-by: Jan Kiszka Cc: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: fix lx-symbols 'gdb.error' while loading modules

2020-07-24T19:42:42+00:00

Commit ed66f991bb19 ("module: Refactor section attr into bin attribute") removed the 'name' field from 'struct module_sect_attr' triggering the following error when invoking lx-symbols: (gdb) lx-symbols loading vmlinux scanning for modules in linux/build loading @0xffffffffc014f000: linux/build/drivers/net/tun.ko Python Exception There is no member named name.: Error occurred in Python: There is no member named name. This patch fixes the issue taking the module name from the 'struct attribute'. Fixes: ed66f991bb19 ("module: Refactor section attr into bin attribute") Signed-off-by: Stefano Garzarella Signed-off-by: Andrew Morton Reviewed-by: Jan Kiszka Reviewed-by: Kieran Bingham Link: http://lkml.kernel.org/r/20200722102239.313231-1-sgarzare@redhat.com Signed-off-by: Linus Torvalds

scripts/gdb: fix debugging modules compiled with hot/cold partitioning

2019-11-06T16:47:50+00:00

gcc's -freorder-blocks-and-partition option makes it group frequently and infrequently used code in .text.hot and .text.unlikely sections respectively. At least when building modules on s390, this option is used by default. gdb assumes that all code is located in .text section, and that .text section is located at module load address. With such modules this is no longer the case: there is code in .text.hot and .text.unlikely, and either of them might precede .text. Fix by explicitly telling gdb the addresses of code sections. It might be tempting to do this for all sections, not only the ones in the white list. Unfortunately, gdb appears to have an issue, when telling it about e.g. loadable .note.gnu.build-id section causes it to think that non-loadable .note.Linux section is loaded at address 0, which in turn causes NULL pointers to be resolved to bogus symbols. So keep using the white list approach for the time being. Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich Reviewed-by: Jan Kiszka Cc: Kieran Bingham Cc: Heiko Carstens Cc: Vasily Gorbik Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: fix debugging modules on s390

2019-10-19T10:32:33+00:00

Currently lx-symbols assumes that module text is always located at module->core_layout->base, but s390 uses the following layout: +------+ <- module->core_layout->base | GOT | +------+ <- module->core_layout->base + module->arch->plt_offset | PLT | +------+ <- module->core_layout->base + module->arch->plt_offset + | TEXT | module->arch->plt_size +------+ Therefore, when trying to debug modules on s390, all the symbol addresses are skewed by plt_offset + plt_size. Fix by adding plt_offset + plt_size to module_addr in load_module_symbols(). Link: http://lkml.kernel.org/r/20191017085917.81791-1-iii@linux.ibm.com Signed-off-by: Ilya Leoshkevich Reviewed-by: Jan Kiszka Cc: Kieran Bingham Cc: Heiko Carstens Cc: Vasily Gorbik Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds