- May 20, 2024
-
-
Thorsten Blum authored
s/does not use unnecessary/do not unnecessarily use/ Signed-off-by:
Thorsten Blum <thorsten.blum@toblux.com> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr>
-
Ricardo Ribalda authored
Most of the people prefer: return ret < 0 ? ret: 0; than: return min(ret, 0); Let's tweak the cocci file to ignore those lines completely. Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr>
-
- May 19, 2024
-
-
Arnd Bergmann authored
All known function cast warnings are now addressed, so the warning can be enabled globally to catch new ones more quickly. Link: https://lkml.kernel.org/r/20240415122037.1983124-6-arnd@kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Arnd Bergmann authored
This warning option still produces output on gcc but is now clean when building with clang, so enable it conditionally on the compiler for now. As far as I can tell, the remaining warnings with gcc are the result of analysing the code more deeply across inlining, while clang only does this within a function. Link: https://lore.kernel.org/lkml/20240326230511.GA2796782@dev-arch.thelio-3990X/ Link: https://lore.kernel.org/linux-patches/20231002-disable-wformat-truncation-overflow-non-kprintf-v1-1-35179205c8d9@kernel.org/ Link: https://lkml.kernel.org/r/20240415122037.1983124-5-arnd@kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Arnd Bergmann authored
All known -Wrestrict warnings are addressed now, so don't disable the warning any more. Link: https://lkml.kernel.org/r/20240415122037.1983124-4-arnd@kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Arnd Bergmann authored
There is no point in turning individual options off and then on again, or vice versa, as the last one always wins. Now that -Wextra always gets passed first, remove all the redundant lines about warnings that are implied by either -Wall or -Wextra, and keep only the last one that disables it in some configurations. This should not have any effect but keep the Makefile more readable and the command line shorter. Link: https://lkml.kernel.org/r/20240415122037.1983124-3-arnd@kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Arnd Bergmann authored
Patch series "kbuild: enable more warnings by default", v3. All the warning fixes I sent for these warnings have been merged into mainline or linux-next, so let's turn them on by default. This patch (of 6): The -Wextra option controls a number of different warnings that differ slightly by compiler version. Some are useful in general, others are better left at W=1 or higher. Based on earlier work, the ones that should be disabled by default are left for the higher warning levels already, and a lot of the useful ones have no remaining output when enabled. Move the -Wextra option up into the set of default-enabled warnings and just rely on the individual ones getting disabled as needed. The -Wunused warning was always grouped with this, so turn it on by default as well, except for the -Wunused-parameter warning that really has no value at all for the kernel since many interfaces have intentionally unused arguments. Link: https://lkml.kernel.org/r/20240415122037.1983124-1-arnd@kernel.org Link: https://lkml.kernel.org/r/20240415122037.1983124-2-arnd@kernel.org Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Nathan Chancellor <nathan@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
- May 15, 2024
-
-
Masahiro Yamada authored
Choices and their members are associated via the P_CHOICE property. Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain the choice of the given choice member. Replace it with sym_get_choice_menu(), which retrieves the choice without relying on P_CHOICE. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- May 14, 2024
-
-
Masahiro Yamada authored
A_NORMAL is zero, so the attribute is set to the default A_NORMAL without explicit assignment. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Just trivial cleanups. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Previously, optional bool choices met the following conditions simultaneously: - sym_is_choice(sym) - sym_is_changeable(sym) - type == S_BOOLEAN It no longer occurs since 6a121588 ("kconfig: remove 'optional' property support"). Remove the dead code. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
This code previously displayed child symbols of the selected choice member. Since commit 7e3465f6 ("kconfig: do not reparent the menu inside a choice block"), choice members never have child symbols, therefore this is dead code. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Currently, bool choices have a checkbox, but tristate choices do not. It is opposite. Bool choices should not have a checkbox, as they are fixed to 'y' since commit 6a121588 ("kconfig: remove 'optional' property support"). Tristate choices, however, should have a checkbox to allow users to toggle the value. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Instead of filtering out the GCOV and KCSAN flags, let's set GCOV_PROFILE and KCSAN_SANITIZE to 'n', as in other Makefiles. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Tested-by:
Roberto Sassu <roberto.sassu@huawei.com>
-
Masahiro Yamada authored
Now Kbuild provides reasonable defaults for objtool, sanitizers, and profilers. Remove redundant variables. Note: This commit changes the coverage for some objects: - include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV - include arch/sparc/vdso/vdso-image-*.o into UBSAN - include arch/sparc/vdso/vma.o into UBSAN - include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vma.o into GCOV, KCOV - include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOV I believe these are positive effects because all of them are kernel space objects. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Tested-by:
Roberto Sassu <roberto.sassu@huawei.com>
-
Masahiro Yamada authored
The objtool, sanitizers (KASAN, UBSAN, etc.), and profilers (GCOV, etc.) are intended only for kernel space objects. For instance, the following are not kernel objects, and therefore should opt out of coverage: - vDSO - purgatory - bootloader (arch/*/boot/) However, to exclude these from coverage, you need to explicitly set OBJECT_FILES_NON_STNDARD=y, KASAN_SANITIZE=n, etc. Kbuild can achieve this without relying on such variables because objects not directly linked to vmlinux or modules are considered "non-standard objects". Detecting standard objects is straightforward: - objects added to obj-y or lib-y are linked to vmlinux - objects added to obj-m are linked to modules There are some exceptional Makefiles (e.g., arch/s390/boot/Makefile, arch/xtensa/boot/lib/Makefile) that use obj-y or lib-y for non-kernel space objects, but they can be fixed later if necessary. Going forward, objects that are not listed in obj-y, lib-y, or obj-m will opt out of objtool, sanitizers, and profilers by default. You can still override the Kbuild decision by explicitly specifying OBJECT_FILES_NON_STANDARD, KASAN_SANITIZE, etc. but most of such Make variables can be removed. The next commit will clean up redundant variables. Note: This commit changes the coverage for some objects: - exclude .vmlinux.export.o from UBSAN, KCOV - exclude arch/csky/kernel/vdso/vgettimeofday.o from UBSAN - exclude arch/parisc/kernel/vdso32/vdso32.so from UBSAN - exclude arch/parisc/kernel/vdso64/vdso64.so from UBSAN - exclude arch/x86/um/vdso/um_vdso.o from UBSAN - exclude drivers/misc/lkdtm/rodata.o from UBSAN, KCOV - exclude init/version-timestamp.o from UBSAN, KCOV - exclude lib/test_fortify/*.o from all santizers and profilers I believe these are positive effects. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Tested-by:
Roberto Sassu <roberto.sassu@huawei.com>
-
Jens Remus authored
Citing Andy Lutomirski from commit dda1e95c ("x86/vdso: Create .build-id links for unstripped vdso files"): "With this change, doing 'make vdso_install' and telling gdb: set debug-file-directory /lib/modules/KVER/vdso will enable vdso debugging with symbols. This is useful for testing, but kernel RPM builds will probably want to manually delete these symlinks or otherwise do something sensible when they strip the vdso/*.so files." Fixes: 4bff8cb5 ("s390: convert to GENERIC_VDSO") Signed-off-by:
Jens Remus <jremus@linux.ibm.com> Signed-off-by:
Alexander Gordeev <agordeev@linux.ibm.com>
-
Yifan Hong authored
If UNUSED_KSYMS_WHITELIST is a file generated before Kbuild runs, and the source tree is in a read-only filesystem, the developer must put the file somewhere and specify an absolute path to UNUSED_KSYMS_WHITELIST. This worked, but if IKCONFIG=y, an absolute path is embedded into .config and eventually into vmlinux, causing the build to be less reproducible when building on a different machine. This patch makes the handling of UNUSED_KSYMS_WHITELIST to be similar to MODULE_SIG_KEY. First, check if UNUSED_KSYMS_WHITELIST is an absolute path, just as before this patch. If so, use the path as is. If it is a relative path, use wildcard to check the existence of the file below objtree first. If it does not exist, fall back to the original behavior of adding $(srctree)/ before the value. After this patch, the developer can put the generated file in objtree, then use a relative path against objtree in .config, eradicating any absolute paths that may be evaluated differently on different machines. Signed-off-by:
Yifan Hong <elsk@google.com> Reviewed-by:
Elliot Berman <quic_eberman@quicinc.com> Signed-off-by:
Luis Chamberlain <mcgrof@kernel.org>
-
Wang Yao authored
Commit ddb5cdba ("kbuild: generate KSYMTAB entries by modpost") forget drop the .export_symbol section from the final modules. Fixes: ddb5cdba ("kbuild: generate KSYMTAB entries by modpost") Signed-off-by:
Wang Yao <wangyao@lemote.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
WANG Rui authored
This commit switches to use the LoongArch's built-in rustc target 'loongarch64-unknown-none-softfloat'. The Rust samples have been tested. Acked-by:
Miguel Ojeda <ojeda@kernel.org> Tested-by:
Miguel Ojeda <ojeda@kernel.org> Signed-off-by:
WANG Rui <wangrui@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- May 11, 2024
-
-
Xining Xu authored
If function-like macros do not utilize a parameter, it might result in a build warning. In our coding style guidelines, we advocate for utilizing static inline functions to replace such macros. This patch verifies compliance with the new rule. For a macro such as the one below, #define test(a) do { } while (0) The test result is as follows. WARNING: Argument 'a' is not used in function-like macro #21: FILE: mm/init-mm.c:20: +#define test(a) do { } while (0) total: 0 errors, 1 warnings, 8 lines checked Link: https://lkml.kernel.org/r/20240507032757.146386-3-21cnbao@gmail.com Signed-off-by:
Xining Xu <mac.xxn@outlook.com> Tested-by:
Barry Song <v-songbaohua@oppo.com> Signed-off-by:
Barry Song <v-songbaohua@oppo.com> Acked-by:
Joe Perches <joe@perches.com> Cc: Chris Zankel <chris@zankel.net> Cc: Huacai Chen <chenhuacai@loongson.cn> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Mark Brown <broonie@kernel.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: Jeff Johnson <quic_jjohnson@quicinc.com> Cc: Charlemagne Lasse <charlemagnelasse@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
- May 09, 2024
-
-
Alan Maguire authored
The btf_features list can be used for pahole v1.26 and later - it is useful because if a feature is not yet implemented it will not exit with a failure message. This will allow us to add feature requests to the pahole options without having to check pahole versions in future; if the version of pahole supports the feature it will be added. Signed-off-by:
Alan Maguire <alan.maguire@oracle.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Tested-by:
Eduard Zingerman <eddyz87@gmail.com> Acked-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240507135514.490467-1-alan.maguire@oracle.com
-
Masahiro Yamada authored
Choices and their members are associated via the P_CHOICE property. Currently, sym_get_choice_prop() and expr_list_for_each_sym() are used to iterate on choice members. Replace them with menu_for_each_sub_entry(), which achieves the same without relying on P_CHOICE. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Choices and their members are associated via the P_CHOICE property. Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain the choice of the given choice member. Replace it with sym_get_choice_menu(), which retrieves the choice without relying on P_CHOICE. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Choices and their members are associated via the P_CHOICE property. Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain the choice of the given choice member. We can do this without relying on P_CHOICE by checking the parent in the menu structure. Introduce a new helper to retrieve the choice if the given symbol is a choice member. This is intended to replace prop_get_symbol(sym_get_choice_prop()) and deprecate P_CHOICE eventually. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
menu_finalize() warns default properties for choice members and prompts outside the choice block. These should be hard errors. While I was here, I moved the checks to slim down menu_finalize(). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Choice members must have a prompt; hence make it an error. While I was here, I moved the check to the parser to slim down _menu_finalize(). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
The return value of conf_choice() is not used. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Following the approach employed in commit bedf9236 ("kconfig: use linked list in get_symbol_str() to iterate over menus"), simplify the iteration on the menus of the specified symbol. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
SYMBOL_CHANGED and MENU_CHANGED are used to update GUI frontends when the symbol value is changed. These are used inconsistently: SYMBOL_CHANGED in gconf.c and MENU_CHANGE in qconf.cc. MENU_CHANGED works more properly when a symbol has multiple prompts (although such code is not ideal). [test code] config FOO bool "foo prompt 1" config FOO bool "foo prompt 2" In gconfig, if one of the two checkboxes is clicked, only the first one is toggled. In xconfig, the two checkboxes work in sync. Replace SYMBOL_CHANGED in gconf.c with MENU_CHANGED to align with the xconfig behavior. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
This is not so useful. If necessary, you can insert printf() or whatever during debugging. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Every time a config file is loaded (either by clicking the "Load" button or selecting "File" -> "Load" from the menu), a new list is appended to the pane. The current tree needs to be cleared by calling gtk_tree_store_clear(). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Emil Renner Berthing authored
Use the KBUILD_IMAGE variable to determine the right kernel image to install and install compressed images to /boot/vmlinuz-$version like the 'make install' target already does. Signed-off-by:
Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
With commit 4b0bf9a0 ("riscv: compat_vdso: install compat_vdso.so.dbg to /lib/modules/*/vdso/") applied, all debug VDSO files are installed in $(MODLIB)/vdso/. Simplify the installation rule. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Currently, Kbuild produces inconsistent results in some cases. You can do an interesting experiment using the --shuffle option, which is supported by GNU Make 4.4 or later. Set CONFIG_KVM_INTEL=y and CONFIG_KVM_AMD=m (or vice versa), and repeat incremental builds w/wo --shuffle=reverse. $ make [ snip ] CC arch/x86/kvm/kvm-asm-offsets.s $ make --shuffle=reverse [ snip ] CC [M] arch/x86/kvm/kvm-asm-offsets.s $ make [ snip ] CC arch/x86/kvm/kvm-asm-offsets.s arch/x86/kvm/kvm-asm-offsets.s is rebuilt every time w/wo the [M] marker. arch/x86/kvm/kvm-asm-offsets.s is built as built-in when it is built as a prerequisite of arch/x86/kvm/kvm-intel.o, which is built-in. arch/x86/kvm/kvm-asm-offsets.s is built as modular when it is built as a prerequisite of arch/x86/kvm/kvm-amd.o, which is a module. Another odd example is single target builds. When CONFIG_LKDTM=m, drivers/misc/lkdtm/rodata.o can be built as built-in or modular, depending on how it is built. $ make drivers/misc/lkdtm/lkdtm.o [ snip ] CC [M] drivers/misc/lkdtm/rodata.o $ make drivers/misc/lkdtm/rodata.o [ snip ] CC drivers/misc/lkdtm/rodata.o drivers/misc/lkdtm/rodata.o is built as modular when it is built as a prerequisite of another, but built as built-in when it is a final target. The same thing happens to drivers/memory/emif-asm-offsets.s when CONFIG_TI_EMIF_SRAM=m. $ make drivers/memory/ti-emif-sram.o [ snip ] CC [M] drivers/memory/emif-asm-offsets.s $ make drivers/memory/emif-asm-offsets.s [ snip ] CC drivers/memory/emif-asm-offsets.s This is because the part-of-module=y flag defined for the modules is inherited by its prerequisites. Target-specific variables are likely intended only for local use. This commit adds 'private' to them. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nicolas Schier <n.schier@avm.de>
-
Masahiro Yamada authored
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for checked-in source files. It is merely a convention without any functional difference. In fact, $(obj) and $(src) are exactly the same, as defined in scripts/Makefile.build: src := $(obj) When the kernel is built in a separate output directory, $(src) does not accurately reflect the source directory location. While Kbuild resolves this discrepancy by specifying VPATH=$(srctree) to search for source files, it does not cover all cases. For example, when adding a header search path for local headers, -I$(srctree)/$(src) is typically passed to the compiler. This introduces inconsistency between upstream and downstream Makefiles because $(src) is used instead of $(srctree)/$(src) for the latter. To address this inconsistency, this commit changes the semantics of $(src) so that it always points to the directory in the source tree. Going forward, the variables used in Makefiles will have the following meanings: $(obj) - directory in the object tree $(src) - directory in the source tree (changed by this commit) $(objtree) - the top of the kernel object tree $(srctree) - the top of the kernel source tree Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced with $(src). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nicolas Schier <nicolas@fjasle.eu>
-
Masahiro Yamada authored
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for checked-in source files. It is merely a convention without any functional difference. In fact, $(obj) and $(src) are exactly the same, as defined in scripts/Makefile.build: src := $(obj) Before changing the semantics of $(src) in the next commit, this commit replaces $(obj)/ with $(src)/ in pattern rules where the prerequisite might be a generated file. C, assembly, Rust, and DTS files are sometimes generated by tools, so they could be either generated files or real sources. The $(obj)/ prefix works for both cases with the help of VPATH. As mentioned above, $(obj) and $(src) are the same at this point, hence this commit has no functional change. I did not modify scripts/Makefile.userprogs because there is no use case where userspace C files are generated. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nicolas Schier <nicolas@fjasle.eu>
-
- May 08, 2024
-
-
Florian Rommel authored
Directly read the current CPU number from the kgdb_active variable. Before, the active CPU was obtained through the current task, which required searching the task list for the pid of GDB's selected thread. Obtaining the pid was buggy: GDB may use selected_thread().ptid[1] (LWPID) instead of .ptid[2] (TID) to store the threads pid; see https://sourceware.org/gdb/current/onlinedocs/gdb.html/Threads-In-Python.html As a result, the detection could return the wrong CPU number, leading to incorrect results for $lx_per_cpu and $lx_current. As a side effect, the patch significantly speeds up $lx_per_cpu and $lx_current in KGDB by avoiding the task-list iteration. Link: https://lkml.kernel.org/r/20240425153501.749966-5-mail@florommel.de Signed-off-by:
Florian Rommel <mail@florommel.de> Cc: Andrew Jones <ajones@ventanamicro.com> Cc: Deepak Gupta <debug@rivosinc.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Cc: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Florian Rommel authored
get_thread_info ($lx_thread_info) only accepted a dereferenced task parameter. Passing a pointer to a task_struct (like $lx_per_cpu does with KGDB) threw an exception. With this patch, both (dereferenced values and pointers) are accepted. Before (on x86, KGDB): >>> p $lx_per_cpu(cpu_info) Traceback (most recent call last): File "./scripts/gdb/linux/cpus.py", line 158, in invoke return per_cpu(var_ptr, cpu) ^^^^^^^^^^^^^^^^^^^^^ File "./scripts/gdb/linux/cpus.py", line 42, in per_cpu cpu = get_current_cpu() ^^^^^^^^^^^^^^^^^ File "./scripts/gdb/linux/cpus.py", line 33, in get_current_cpu return tasks.get_thread_info(tasks.get_task_by_pid(tid))['cpu'] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "./scripts/gdb/linux/tasks.py", line 88, in get_thread_info if task.type.fields()[0].type == thread_info_type.get_type(): ~~~~~~~~~~~~~~~~~~^^^ IndexError: list index out of range Link: https://lkml.kernel.org/r/20240425153501.749966-4-mail@florommel.de Signed-off-by:
Florian Rommel <mail@florommel.de> Cc: Andrew Jones <ajones@ventanamicro.com> Cc: Deepak Gupta <debug@rivosinc.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Cc: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Florian Rommel authored
Before, the script tried to get the address by constructing a pointer to the parameter (by name). However, since GDB now passes the parameter as a GdbValue, we cannot get its name. Instead, we retrieve the address through GdbValue's address attribute. Before: >>> p $lx_per_cpu(cpu_info) Traceback (most recent call last): File "./scripts/gdb/linux/cpus.py", line 152, in invoke var_ptr = gdb.parse_and_eval("&" + var_name.string()) ^^^^^^^^^^^^^^^^^ gdb.error: Trying to read string with inappropriate type `struct cpuinfo_x86'. Link: https://lkml.kernel.org/r/20240425153501.749966-3-mail@florommel.de Signed-off-by:
Florian Rommel <mail@florommel.de> Cc: Andrew Jones <ajones@ventanamicro.com> Cc: Deepak Gupta <debug@rivosinc.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Cc: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-