user/sven/linux.git/scripts/gdb, branch v5.15.111

scripts/gdb: fix lx-timerlist for Python3

2023-05-11T14:00:39Z

commit 7362042f3556528e9e9b1eb5ce8d7a3a6331476b upstream. Below incompatibilities between Python2 and Python3 made lx-timerlist fail to run under Python3. o xrange() is replaced by range() in Python3 o bytes and str are different types in Python3 o the return value of Inferior.read_memory() is memoryview object in Python3 akpm: cc stable so that older kernels are properly debuggable under newer Python. Link: https://lkml.kernel.org/r/TYCP286MB2146EE1180A4D5176CBA8AB2C6819@TYCP286MB2146.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Peng Liu Reviewed-by: Jan Kiszka Cc: Florian Fainelli Cc: Kieran Bingham Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

scripts/gdb: raise error with reduced debugging information

2023-05-11T14:00:33Z

[ Upstream commit 8af055ae25bff48f57227f5e3d48a4306f3dd1c4 ] If CONFIG_DEBUG_INFO_REDUCED is enabled in the kernel configuration, we will typically not be able to load vmlinux-gdb.py and will fail with: Traceback (most recent call last): File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/vmlinux-gdb.py", line 25, in import linux.utils File "/home/fainelli/work/buildroot/output/arm64/build/linux-custom/scripts/gdb/linux/utils.py", line 131, in atomic_long_counter_offset = atomic_long_type.get_type()['counter'].bitpos KeyError: 'counter' Rather be left wondering what is happening only to find out that reduced debug information is the cause, raise an eror. This was not typically a problem until e3c8d33e0d62 ("scripts/gdb: fix 'lx-dmesg' on 32 bits arch") but it has since then. Link: https://lkml.kernel.org/r/20230406215252.1580538-1-f.fainelli@gmail.com Fixes: e3c8d33e0d62 ("scripts/gdb: fix 'lx-dmesg' on 32 bits arch") Signed-off-by: Florian Fainelli Cc: Antonio Borneo Cc: Jan Kiszka Cc: John Ogness Cc: Kieran Bingham Cc: Petr Mladek Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

scripts/gdb: bail early if there are no generic PD

2023-05-11T14:00:33Z

[ Upstream commit f19c3c2959e465209ade1a7a699e6cbf4359ce78 ] Avoid generating an exception if there are no generic power domain(s) registered: (gdb) lx-genpd-summary domain status children /device runtime status ---------------------------------------------------------------------- Python Exception : No symbol "gpd_list" in current context. Error occurred in Python: No symbol "gpd_list" in current context. (gdb) quit [f.fainelli@gmail.com: correctly invoke gdb_eval_or_none] Link: https://lkml.kernel.org/r/20230327185746.3856407-1-f.fainelli@gmail.com Link: https://lkml.kernel.org/r/20230323231659.3319941-1-f.fainelli@gmail.com Fixes: 8207d4a88e1e ("scripts/gdb: add lx-genpd-summary command") Signed-off-by: Florian Fainelli Cc: Jan Kiszka Cc: Kieran Bingham Cc: Leonard Crestez Cc: Stephen Boyd Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

scripts/gdb: bail early if there are no clocks

2023-05-11T14:00:33Z

[ Upstream commit 1d7adbc74c009057ed9dc3112f388e91a9c79acc ] Avoid generating an exception if there are no clocks registered: (gdb) lx-clk-summary enable prepare protect clock count count count rate ------------------------------------------------------------------------ Python Exception : No symbol "clk_root_list" in current context. Error occurred in Python: No symbol "clk_root_list" in current context. Link: https://lkml.kernel.org/r/20230323225246.3302977-1-f.fainelli@gmail.com Fixes: d1e9710b63d8 ("scripts/gdb: initial clk support: lx-clk-summary") Signed-off-by: Florian Fainelli Cc: Jan Kiszka Cc: Kieran Bingham Cc: Leonard Crestez Cc: Stephen Boyd Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

scripts/gdb: fix 'lx-dmesg' on 32 bits arch

2022-08-17T12:23:56Z

[ Upstream commit e3c8d33e0d62175c31ca7ab7ab01b18f0b6318d3 ] The type atomic_long_t can have size 4 or 8 bytes, depending on CONFIG_64BIT; it's only content, the field 'counter', is either an int or a s64 value. Current code incorrectly uses the fixed size utils.read_u64() to read the field 'counter' inside atomic_long_t. On 32 bits architectures reading the last element 'tail_id' of the struct prb_desc_ring: struct prb_desc_ring { ... atomic_long_t tail_id; }; causes the utils.read_u64() to access outside the boundary of the struct and the gdb command 'lx-dmesg' exits with error: Python Exception : index out of range Error occurred in Python: index out of range Query the really used atomic_long_t counter type size. Link: https://lore.kernel.org/r/20220617143758.137307-1-antonio.borneo@foss.st.com Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer") Signed-off-by: Antonio Borneo [pmladek@suse.com: Query the really used atomic_long_t counter type size] Tested-by: Antonio Borneo Reviewed-by: John Ogness Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220719122831.19890-1-pmladek@suse.com Signed-off-by: Sasha Levin

scripts/gdb: lx-dmesg: read records individually

2022-08-17T12:23:56Z

[ Upstream commit deaee2704a157dfcca77301ddaa10c62a9840952 ] For the gdb command lx-dmesg, the entire descriptor, info, and text data regions are read into memory before printing any records. For large kernel log buffers, this not only causes a huge delay before seeing any records, but it may also lead to python errors of too much memory allocation. Rather than reading in all these regions in advance, read them as needed and only read the regions for the particular record that is being printed. The gdb macro "dmesg" in Documentation/admin-guide/kdump/gdbmacros.txt already prints out the kernel log buffer like this. Signed-off-by: John Ogness Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/874k79c3a9.fsf@jogness.linutronix.de Signed-off-by: Sasha Levin

scripts/gdb: change kernel config dumping method

2022-06-14T16:36:24Z

[ Upstream commit 1f7a6cf6b07c74a17343c2559cd5f5018a245961 ] MAGIC_START("IKCFG_ST") and MAGIC_END("IKCFG_ED") are moved out from the kernel_config_data variable. Thus, we parse kernel_config_data directly instead of considering offset of MAGIC_START and MAGIC_END. Fixes: 13610aa908dc ("kernel/configs: use .incbin directive to embed config_data.gz") Signed-off-by: Kuan-Ying Lee Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts/gdb: add lx_current support for arm64

2021-05-07T07:26:33Z

arm64 uses SP_EL0 to save the current task_struct address. While running in EL0, SP_EL0 is clobbered by userspace. So if the upper bit is not 1 (not TTBR1), the current address is invalid. This patch checks the upper bit of SP_EL0, if the upper bit is 1, lx_current() of arm64 will return the derefrence of current task. Otherwise, lx_current() will tell users they are running in userspace(EL0). While arm64 is running in EL0, it is actually pointless to print current task as the memory of kernel space is not accessible in EL0. Link: https://lkml.kernel.org/r/20210314203444.15188-3-song.bao.hua@hisilicon.com Signed-off-by: Barry Song Cc: Jan Kiszka Cc: Jonathan Corbet Cc: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

scripts/gdb: document lx_current is only supported by x86

2021-05-07T07:26:33Z

Patch series "scripts/gdb: clarify the platforms supporting lx_current and add arm64 support", v2. lx_current depends on per_cpu current_task variable which exists on x86 only. so it actually works on x86 only. the 1st patch documents this clearly; the 2nd patch adds support for arm64. This patch (of 2): x86 is the only architecture which has per_cpu current_task: arch$ git grep current_task | grep -i per_cpu x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *, current_task); x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) ____cacheline_aligned = x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task); x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) = &init_task; x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task); x86/kernel/smpboot.c: per_cpu(current_task, cpu) = idle; On other architectures, lx_current() will lead to a python exception: (gdb) p $lx_current().pid Python Exception No symbol "current_task" in current context.: Error occurred in Python: No symbol "current_task" in current context. To avoid more people struggling and wasting time in other architectures, document it. Link: https://lkml.kernel.org/r/20210314203444.15188-1-song.bao.hua@hisilicon.com Link: https://lkml.kernel.org/r/20210314203444.15188-2-song.bao.hua@hisilicon.com Signed-off-by: Barry Song Cc: Jan Kiszka Cc: Kieran Bingham Cc: Jonathan Corbet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

gdb: lx-symbols: store the abspath()

2021-05-07T07:26:32Z

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