scripts/gdb/symbols: determine KASLR offset on s390

Use QEMU's qemu.PhyMemMode [1] functionality to read vmcore from the
physical memory the same way the existing dump tooling does this.
Gracefully

scripts/gdb/symbols: determine KASLR offset on s390

Use QEMU's qemu.PhyMemMode [1] functionality to read vmcore from the
physical memory the same way the existing dump tooling does this.
Gracefully handle non-QEMU targets, early boot, and memory corruptions;
print a warning if such situation is detected.

[1] https://qemu-project.gitlab.io/qemu/system/gdb.html#examining-physical-memory

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Ilya Leoshkevich <[email protected]>
Acked-by: Jan Kiszka <[email protected]>
Cc: Alexander Gordeev <[email protected]>
Cc: Andrew Donnellan <[email protected]>
Cc: Christian Borntraeger <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Nina Schoetterl-Glausch <[email protected]>
Cc: Vasily Gorbik <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/gdb/linux/symbols.py: address changes to module_sect_attrs

When loading symbols from kernel modules we used to iterate
from 0 to module_sect_attrs::nsections, in order to
retrieve their name

scripts/gdb/linux/symbols.py: address changes to module_sect_attrs

When loading symbols from kernel modules we used to iterate
from 0 to module_sect_attrs::nsections, in order to
retrieve their name and address.

However module_sect_attrs::nsections has been removed from
the struct by a previous commit.

Re-arrange the iteration by accessing all items in
module_sect_attrs::grp::bin_attrs[] until NULL is found
(it's a NULL terminated array).

At the same time the symbol address cannot be extracted
from module_sect_attrs::attrs[]::address anymore because
it has also been deleted. Fetch it from
module_sect_attrs::grp::bin_attrs[]::private as described
in 4b2c11e4aaf7.

Link: https://lkml.kernel.org/r/[email protected]
Fixes: d8959b947a8d ("module: sysfs: Drop member 'module_sect_attrs::nsections'")
Fixes: 4b2c11e4aaf7 ("module: sysfs: Drop member 'module_sect_attr::address'")
Signed-off-by: Antonio Quartulli <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Cc: Thomas Weißschuh <[email protected]>
Cc: Kieran Bingham <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

gdb: lx-symbols: do not error out on monolithic build

This avoids spurious message:
(gdb) lx-symbols
loading vmlinux
No source file named kernel/module/main.c.

Link: https://lkml.kernel.org/r/Zy5AL

gdb: lx-symbols: do not error out on monolithic build

This avoids spurious message:
(gdb) lx-symbols
loading vmlinux
No source file named kernel/module/main.c.

Link: https://lkml.kernel.org/r/Zy5ALByQtpO-ddh4@Z926fQmE5jqhFMgp6
Signed-off-by: Etienne Buira <[email protected]>
Cc: Andrew Ballance <[email protected]>
Cc: Kieran Bingham <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/gdb/symbols: fix invalid escape sequence warning

With python 3.12, '\.' results in this warning
SyntaxWarning: invalid escape sequence '\.'

Link: https://lkml.kernel.org/r/2024030401250

scripts/gdb/symbols: fix invalid escape sequence warning

With python 3.12, '\.' results in this warning
SyntaxWarning: invalid escape sequence '\.'

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrew Ballance <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Koudai Iwahori <[email protected]>
Cc: Kuan-Ying Lee <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: Pankaj Raghav <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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

Revert 11f956538c07 ("scripts/gdb/symbols: add specific ko module load
command") due to breakage identified by Johannes Berg in [1].

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

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 <[email protected]>
Closes: https://lkml.kernel.org/r/[email protected] [1]
Cc: AngeloGioacchino Del Regno <[email protected]>
Cc: Chinwen Chang <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Kuan-Ying Lee <[email protected]>
Cc: Matthias Brugger <[email protected]>
Cc: Qun-Wei Lin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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

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

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

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 <ko_path> 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/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Kuan-Ying Lee <[email protected]>
Cc: AngeloGioacchino Del Regno <[email protected]>
Cc: Chinwen Chang <[email protected]>
Cc: Matthias Brugger <[email protected]>
Cc: Qun-Wei Lin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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

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, .tex

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

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/[email protected]
Signed-off-by: Koudai Iwahori <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

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

commit ac3b43283923 ("module: replace module_layout with module_memory")
changed the struct module data structure from module_la

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

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 <class 'gdb.error'>: 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 <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>

show more ...

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

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 ker

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

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 <[email protected]>
Acked-by: Luis Chamberlain <[email protected]>
Fixes: cfc1d277891e ("module: Move all into module/")
Reviewed-by: Douglas Anderson <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: handle split debug for vmlinux

This is related to two previous changes. Commit dfe4529ee4d3
("scripts/gdb: find vmlinux where it was before") and commit da036ae14762
("scripts/gdb: han

scripts/gdb: handle split debug for vmlinux

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 <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Johannes Berg <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

gdb: lx-symbols: store the abspath()

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 i

gdb: lx-symbols: store the abspath()

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 <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

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

Commit ed66f991bb19 ("module: Refactor section attr into bin attribute")
removed the 'name' field from 'struct module_sect_attr' trigger

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

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 <class 'gdb.error'> 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 <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Reviewed-by: Kieran Bingham <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

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

gcc's -freorder-blocks-and-partition option makes it group frequently
and infrequently used code in .text.hot and .text.unlikel

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

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/[email protected]
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: Vasily Gorbik <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: fix debugging modules on s390

Currently lx-symbols assumes that module text is always located at
module->core_layout->base, but s390 uses the following layout:

+------+ <- module->c

scripts/gdb: fix debugging modules on s390

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/[email protected]
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Heiko Carstens <[email protected]>
Cc: Vasily Gorbik <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: handle split debug

Some systems (like Chrome OS) may use "split debug" for kernel modules.
That means that the debug symbols are in a different file than the main
elf file. Let's handl

scripts/gdb: handle split debug

Some systems (like Chrome OS) may use "split debug" for kernel modules.
That means that the debug symbols are in a different file than the main
elf file. Let's handle that by also searching for debug symbols that end
in ".ko.debug".

This is a packaging topic. You can take a normal elf file and split the
debug out of it using objcopy. Try "man objcopy" and then take a look at
the "--only-keep-debug" option. It'll give you a whole recipe for doing
splitdebug. The suffix used for the debug symbols is arbitrary. If
people have other another suffix besides ".ko.debug" then we could
presumably support that too...

For portage (which is the packaging system used by Chrome OS) split debug
is supported by default (and the suffix is .ko.debug). ...and so in
Chrome OS we always get the installed elf files stripped and then the
symbols stashed away.

At the moment we don't actually use the normal portage magic to do this
for the kernel though since it affects our ability to get good stack dumps
in the kernel. We instead pass a script as "strip" [1].

[1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/eclass/cros-kernel/strip_splitdebug

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: Daniel Thompson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: find vmlinux where it was before

Patch series "gdb script for kconfig and timer list".

This is a handful of changes to the kernel's gdb scripts to do some more
debugging with kgdb. Th

scripts/gdb: find vmlinux where it was before

Patch series "gdb script for kconfig and timer list".

This is a handful of changes to the kernel's gdb scripts to do some more
debugging with kgdb. The first patch allows the vmlinux to be reloaded
from where it was specified on the command line so that this set of
scripts can be used from anywhere. The second patch adds a script to
dump the config.gz to a file on the host debugging machine. The third
patch adds some rb tree utilities and the last patch uses those rb tree
walking utilities to dump out the contents of /proc/timer_list from a
system under debug.

This patch (of 5):

If I run 'gdb <path/to/vmlinux>' and there's the vmlinux-gdb.py file
there I can properly see symbols and use the lx commands provided by the
GDB scripts. But once I run 'lx-symbols' at the command prompt, gdb
reloads the vmlinux symbols assuming that this script was run from the
directory that has vmlinux at the root. That isn't always true, but we
could just look and see what symbols were already loaded and use that
instead. Let's do that so this can work by being invoked anywhere.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Nikolay Borisov <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: Jackie Liu <[email protected]>
Cc: Jason Wessel <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: Perform path expansion to lx-symbol's arguments

Python doesn't do automatic expansion of paths. In case one passes path
of the from ~/foo/bar the gdb scripts won't automatically expand

scripts/gdb: Perform path expansion to lx-symbol's arguments

Python doesn't do automatic expansion of paths. In case one passes path
of the from ~/foo/bar the gdb scripts won't automatically expand that
and as a result the symbols files won't be loaded.

Fix this by explicitly expanding all paths which begin with "~"

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Nikolay Borisov <[email protected]>
Signed-off-by: Kieran Bingham <[email protected]>
Reviewed-by: Jan Kiszka <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: account for changes in module data structure

Commit 7523e4dc5057 ("module: use a structure to encapsulate layout.")
factored out the module_layout structure. Adjust the symbol loader a

scripts/gdb: account for changes in module data structure

Commit 7523e4dc5057 ("module: use a structure to encapsulate layout.")
factored out the module_layout structure. Adjust the symbol loader and
the lsmod command to this.

Signed-off-by: Jan Kiszka <[email protected]>
Reviewed-by: Kieran Bingham <[email protected]>
Tested-by: Kieran Bingham <[email protected]> (qemu-{ARM,x86})
Cc: Rusty Russell <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: <[email protected]> [4.4+]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: fix PEP8 compliance

Signed-off-by: Thiébaud Weksteen <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
S

scripts/gdb: fix PEP8 compliance

Signed-off-by: Thiébaud Weksteen <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: disable pagination while printing from breakpoint handler

While reporting the (refreshed) list of modules on automatic updates we
may hit the page boundary of the output console and cau

scripts/gdb: disable pagination while printing from breakpoint handler

While reporting the (refreshed) list of modules on automatic updates we
may hit the page boundary of the output console and cause a stop if
pagination is enabled. However, gdb does not accept user input while
running over the breakpoint handler. So we get stuck, and the user is
forced to interrupt gdb.

Resolve this by disabling pagination during automatic symbol updates. We
restore the user's configuration once done.

Signed-off-by: Jan Kiszka <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Borislav Petkov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: convert ModuleList to generator function

Analogously to the task list, convert the module list to a generator
function. It noticeably simplifies the code.

Signed-off-by: Jan Kiszka <j

scripts/gdb: convert ModuleList to generator function

Analogously to the task list, convert the module list to a generator
function. It noticeably simplifies the code.

Signed-off-by: Jan Kiszka <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Borislav Petkov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: port to python3 / gdb7.7

I tried to use these scripts in an ubuntu 14.04 host (gdb 7.7 compiled
against python 3.3) but there were several errors.

I believe this patch fixes these issu

scripts/gdb: port to python3 / gdb7.7

I tried to use these scripts in an ubuntu 14.04 host (gdb 7.7 compiled
against python 3.3) but there were several errors.

I believe this patch fixes these issues so that the commands now work (I
tested lx-symbols, lx-dmesg, lx-lsmod).

Main issues that needed to be resolved:

* In python 2 iterators have a "next()" method. In python 3 it is
__next__() instead (so let's just add both).

* In older python versions there was an implicit conversion
in object.__format__() (used when an object is in string.format())
where it was converting the object to str first and then
calling str's __format__(). This has now been removed so
we must explicitly convert to str the objects for which
we need to keep this behavior.

* In dmesg.py: in python 3 log_buf is now a "memoryview" object
which needs to be converted to a string in order to use string
methods like "splitlines()". Luckily memoryview exists in
python 2.7.6 as well, so we can convert log_buf to memoryview
and use the same code in both python 2 and python 3.

This version of the patch has now been tested with gdb 7.7 and both python
3.4 and python 2.7.6 (I think asking for at least python 2.7.6 is a
reasonable requirement instead of complicating the code with version
checks etc).

Signed-off-by: Pantelis Koukousoulas <[email protected]>
Signed-off-by: Jan Kiszka <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Borislav Petkov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: add automatic symbol reloading on module insertion

This installs a silent breakpoint on the do_init_module function. The
breakpoint handler will try to load symbols from the module fil

scripts/gdb: add automatic symbol reloading on module insertion

This installs a silent breakpoint on the do_init_module function. The
breakpoint handler will try to load symbols from the module files found
during lx-symbols execution. This way, breakpoints can be set to module
initialization functions, and there is no need to explicitly call
lx-symbols after (re-)loading a module.

Signed-off-by: Jan Kiszka <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Borislav Petkov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/gdb: add lx-symbols command

This is probably the most useful helper when debugging kernel modules:
lx-symbols first reloads vmlinux. Then it searches recursively for *.ko
files in the speci

scripts/gdb: add lx-symbols command

This is probably the most useful helper when debugging kernel modules:
lx-symbols first reloads vmlinux. Then it searches recursively for *.ko
files in the specified paths and the current directory. Finally it walks
the kernel's module list, issuing the necessary add-symbol-file command
for each loaded module so that gdb knows which module symbol corresponds
to which address. It also looks up variable sections (bss, data, rodata)
and appends their address to the add-symbole-file command line. This
allows to access global module variables just like any other variable.

Signed-off-by: Jan Kiszka <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Wessel <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Ben Widawsky <[email protected]>
Cc: Borislav Petkov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...