[PATCH 0/4] Add cross compilation and CI build
by Lianbo Jiang
The patchset will add cross compilation and CI build
for crash-utility, includes four patches:
[1] [PATCH 1/4] sparc64: fix build failure
[2] [PATCH 2/4] gdb:disable building gdbserver in crash-utility
This will speed up crash building and save time, also avoid
some compilation issues, the [3] and [4] will benefit from
this one.
[3] [PATCH 3/4] Add cross compilation support
E.g: cross build crash-utility for aarch64 on X86_64
make CROSS_COMPILE=aarch64-linux-gnu- -j`nproc`
or
make CROSS_COMPILE=aarch64-linux-gnu- -j`nproc` warn
Note: there are still some limitations for cross
compilation because some dependency libs that are not
cross-compiled, for example: snappy, lzo, zstd
[4] [PATCH 4/4] Add ci-build.yml
Add a CI build and enable it on multiple arches, which can
check for compilation issues and also reduce some maintaince
workload.
Please refer to the result of CI build:
https://github.com/lian-bo/crash/actions/runs/13413391349
Lianbo Jiang (4):
sparc64: fix build failure
gdb:disable building gdbserver in crash-utility
Add cross compilation support
Add ci-build.yml
.github/workflows/ci-build.yml | 71 ++++++++++++++++++++++++++++++++++
Makefile | 50 +++++++++++++++++++++++-
README | 5 +++
configure.c | 6 +++
defs.h | 2 +-
gdb-10.2.patch | 12 ++++++
help.c | 5 +++
7 files changed, 148 insertions(+), 3 deletions(-)
create mode 100644 .github/workflows/ci-build.yml
--
2.47.1
2 days, 4 hours
Re: [PATCH v2 0/3] Update to gdb-16.2
by lijiang
On Thu, Feb 6, 2025 at 3:05 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Thu, 6 Feb 2025 20:04:11 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH v2 0/3] Update to gdb-16.2
> To: devel(a)lists.crash-utility.osci.io
> Cc: Tao Liu <ltao(a)redhat.com>
> Message-ID: <20250206070418.1038668-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> v2 -> v1: Splite the "Fix several build failures" patchset, which is
> already merged btw, from gdb v16.2 upgrading.
>
Thank you for the update, Tao.
I will have a look next week.
Thanks
Lianbo
>
> Tao Liu (3):
> LoongArch64: Revert all previous LoongArch64 related commits
> Revert: Fix C99 compatibility issues in embedded copy of GDB
> Update to gdb-16.2
>
> Makefile | 10 +-
> README | 6 +-
> configure.c | 64 +-
> crash.8 | 2 +-
> crash_target.c | 6 +-
> defs.h | 174 +-
> diskdump.c | 24 +-
> gdb-10.2.patch | 16323 ------------------------------------------
> gdb-16.2.patch | 2254 ++++++
> gdb_interface.c | 14 +-
> help.c | 15 +-
> kernel.c | 6 +-
> lkcd_vmdump_v1.h | 2 +-
> lkcd_vmdump_v2_v3.h | 5 +-
> loongarch64.c | 1368 ----
> main.c | 3 +-
> netdump.c | 27 +-
> ramdump.c | 2 -
> symbols.c | 37 +-
> 19 files changed, 2322 insertions(+), 18020 deletions(-)
> delete mode 100644 gdb-10.2.patch
> create mode 100644 gdb-16.2.patch
> delete mode 100644 loongarch64.c
>
> --
> 2.47.0
>
5 days, 4 hours
[PATCH] symbols: redetermine the end of kernel range for in_ksymbol_range
by Tao Liu
For in_ksymbol_range(), it determine the kernel range by st->symtable[0].value
as the start and st->symtable[st->symcnt-1].value as the end, this
however, implies the last element is in the kernel range. In most
cases it was correct, but it is no longer valid with the kernel commit [1].
The xen_elfnote_phys32_entry_value introduced by [1], is beyound the kernel
range(doesn't belong to any kernel section), thus doesn't get relocated
by relocate(). So in order to have a correct in_ksymbol_range(), we need
to eliminate those symbols.
Without the patch:
crash> sym schedule
ffffffff973ffb30 (T) schedule /root/linux-6.14-rc3/kernel/sched/core.c: 6848
crash> sym 0xffffffff973ffb30
sym: invalid address: 0xffffffff973ffb30
With the patch:
crash> sym schedule
ffffffff973ffb30 (T) schedule /root/linux-6.14-rc3/kernel/sched/core.c: 6848
crash> sym 0xffffffff973ffb30
ffffffff973ffb30 (T) schedule /root/linux-6.14-rc3/kernel/sched/core.c: 6848
[1]: https://github.com/torvalds/linux/commit/223abe96ac0d227b22d48ab447dd9384...
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
v2 -> v1: In fact the gnu_qsort() does sort the symbols with no
problem, unlike the root cause described in v1. It's because
xen_elfnote_phys32_entry_value doesn't belong to any kernel
section, so the
symval >= st->first_section_start && symval <= st->last_section_end
check will not success in relocate(), so the symbol is not relocated.
But I'm not sure if xen_elfnote_phys32_entry_value should be
relocated or not, it looks to be an absoluate symbol to me,
but the code comment is not very clear...
v1 patch: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01373.html
v1 discussion: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01378.html
---
---
symbols.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/symbols.c b/symbols.c
index 6385d02..edbafa4 100644
--- a/symbols.c
+++ b/symbols.c
@@ -5443,8 +5443,14 @@ old_module:
int
in_ksymbol_range(ulong value)
{
+ int i;
+ for (i = st->symcnt-1; i >= 0; i--) {
+ if (!strstr(st->symtable[i].name, "xen_elfnote"))
+ break;
+ }
+
if ((value >= st->symtable[0].value) &&
- (value <= st->symtable[st->symcnt-1].value)) {
+ (value <= st->symtable[i].value)) {
if ((st->flags & PERCPU_SYMS) && (value < st->first_ksymbol))
return FALSE;
else
--
2.47.0
2 weeks, 4 days
Re: [PATCH 0/3] Several fixes for v6.14-rc kernels
by lijiang
Thank you for the fix, Tao.
On Mon, Feb 24, 2025 at 11:02 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Mon, 24 Feb 2025 15:59:11 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH 0/3] Several fixes for v6.14-rc
> kernels
> To: devel(a)lists.crash-utility.osci.io
> Cc: andersonc0d3(a)gmail.com, Tao Liu <ltao(a)redhat.com>
> Message-ID: <20250224025914.16044-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> There are a few failing cases observed on v6.14-rc kernel. This patchset
> will fix these.
>
> For the NO.1 patch, Anderson used "vtop" cmd as the test case [1], which I
> cannot reproduce because I didn't find a suitable value for vtop to
> trigger the failing. So I switched to "files" cmd.
>
> [1]:
> https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01356.html
>
> Tao Liu (3):
> Fix the failing of cmd "files" for v6.14-rc1 kernel
> Fix the failing of cmd "runq -g" for v6.14-rc1 kernel
>
The patch [1] and [2] are fine to me, applied:
[1]
https://github.com/crash-utility/crash/commit/2795136a515446b798ebbfa257c...
[2]
https://github.com/crash-utility/crash/commit/080b4baf5d5e998750f80289c84...
Sort the symtable at the end of store_symbols()
>
>
For the patch [3], I did not reproduce the current issue, can you try to
provide some unsorted symbols information?
Maybe there are similar cases such as store_sysmap_symbols.
Thanks
Lianbo
> filesys.c | 3 +++
> symbols.c | 3 +++
> task.c | 3 +++
> 3 files changed, 9 insertions(+)
>
> --
> 2.47.0
>
2 weeks, 5 days
[PATCH 0/3] Several fixes for v6.14-rc kernels
by Tao Liu
There are a few failing cases observed on v6.14-rc kernel. This patchset
will fix these.
For the NO.1 patch, Anderson used "vtop" cmd as the test case [1], which I
cannot reproduce because I didn't find a suitable value for vtop to
trigger the failing. So I switched to "files" cmd.
[1]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01356.html
Tao Liu (3):
Fix the failing of cmd "files" for v6.14-rc1 kernel
Fix the failing of cmd "runq -g" for v6.14-rc1 kernel
Sort the symtable at the end of store_symbols()
filesys.c | 3 +++
symbols.c | 3 +++
task.c | 3 +++
3 files changed, 9 insertions(+)
--
2.47.0
2 weeks, 6 days
[PATCH v2 0/5] gdb multi-stack unwinding support
by Tao Liu
This patchset is based on Alexy's work [1], and is the follow-up of the
previous "gdb stack unwinding support for crash utility" patchset.
Currently gdb target analyzes only one task at a time and it backtraces
only straight stack until end of the stack. If stacks were concatenated
during exceptions or interrupts, gdb bt will show only the topmost one.
This patchset will introduce multiple stacks support for gdb stack unwinding,
which can be observed as a different threads from gdb perspective. A
short usage is as follows:
'set <PID>' - to switch to a specific task
'gdb info threads' - to see list of in-kernel stacks of this task.
'gdb thread <ID>' - to switch to the stack.
'gdb bt' - to unwind it.
E.g, with the patchset:
crash> bt
PID: 17636 TASK: ffff88032e0742c0 CPU: 11 COMMAND: "kworker/11:4"
#0 [ffff88037fca6b58] machine_kexec at ffffffff8103cef2
#1 [ffff88037fca6ba8] crash_kexec at ffffffff810c9aa3
#2 [ffff88037fca6c70] panic at ffffffff815f0444
...
#9 [ffff88037fca6ec8] do_nmi at ffffffff815fd980
#10 [ffff88037fca6ef0] end_repeat_nmi at ffffffff815fcec1
[exception RIP: memcpy+13]
RIP: ffffffff812f5b1d RSP: ffff88034f2a9728 RFLAGS: 00010046
RAX: ffffc900139fe000 RBX: ffff880374b7a1b0 RCX: 0000000000000030
RBP: ffff88034f2a9778 R8: 000000007fffffff R9: 00000000ffffffff
...
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
--- <NMI exception stack> ---
#11 [ffff88034f2a9728] memcpy at ffffffff812f5b1d
#12 [ffff88034f2a9728] mga_dirty_update at ffffffffa024ad2b [mgag200]
#13 [ffff88034f2a9780] mga_imageblit at ffffffffa024ae3f [mgag200]
#14 [ffff88034f2a97a0] bit_putcs at ffffffff813424ef
...
crash> info threads
Id Target Id Frame
* 1 17636 kworker/11:4 (stack 0) crash_setup_regs (oldregs=0x0, newregs=0xffff88037fca6bb0)
2 17636 kworker/11:4 (stack 1) 0xffffffff812f5b1d in memcpy ()
crash> thread 2
crash> gdb bt
#0 0xffffffff812f5b1d in memcpy () at arch/x86/lib/memcpy_64.S:69
...
There are 2 stacks of the current task, and we can list/switch-to/unwind
each stack.
[1]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01204.html
v2 -> v1: 1) Rebase this patchset onto gdb-16.2 [2].
2) Improved the silent_call_bt() to catch the error FATAL.
[2]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01354.html
Tao Liu (5):
Add multi-threads support in crash target
Call cmd_bt silently after "set pid"
x86_64: Add gdb multi-stack unwind support
arm64: Add gdb multi-stack unwind support
ppc64: Add gdb multi-stack unwind support
arm64.c | 85 +++++++++++++++++++++++++++++++--
crash_target.c | 49 +++++++++++++++++--
defs.h | 3 +-
gdb_interface.c | 6 +--
kernel.c | 43 +++++++++++++++++
ppc64.c | 70 +++++++++++++++++++++++----
task.c | 4 +-
x86_64.c | 123 +++++++++++++++++++++++++++++++++++++++++++++---
8 files changed, 354 insertions(+), 29 deletions(-)
--
2.47.0
3 weeks, 2 days
Re: Crash errors when using vtop command on the Linux kernel v6.14-rc1
by lijiang
On Thu, Feb 20, 2025 at 10:12 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Mon, 17 Feb 2025 11:52:21 -0300
> From: Anderson Nascimento <andersonc0d3(a)gmail.com>
> Subject: [Crash-utility] Crash errors when using vtop command on the
> Linux kernel v6.14-rc1
> To: devel(a)lists.crash-utility.osci.io
> Message-ID:
> <CANUJ=ykSypFt-CEzSXtoXvMThoD_Stpg2c95P=
> g5DW2CvS13ow(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello all,
>
> I built the Linux kernel version 6.14-rc1 on Fedora 41 and the crash
> utility doesn't
> work as expected on it. Quickly investigating the issue, the commit below
> from last month changes a field in the struct dentry and it seems to
> be the reason for the errors I am seeing.
>
> dcache: back inline names with a struct-wrapped array of unsigned long
>
> https://github.com/torvalds/linux/commit/58cf9c383c5c686668082f83f7e0f3e0...
>
>
Thank you for reporting and investigating this issue, Anderson Nascimento.
The errors are the following:
>
> crash> vtop -c 1224 0x41400000
> VIRTUAL PHYSICAL
> 41400000 51144000
>
> PGD: 24438000 => dfaf067
> PUD: dfaf008 => 109fd067
> PMD: 109fd050 => fc07067
> PTE: fc07000 => 8000000051144867
> PAGE: 51144000
>
> PTE PHYSICAL FLAGS
> 8000000051144867 51144000 (PRESENT|RW|USER|ACCESSED|DIRTY|NX)
>
> VMA START END FLAGS FILE
>
> vtop: invalid structure member offset: dentry_d_iname
> FILE: filesys.c LINE: 3242 FUNCTION: get_pathname_component()
>
> BFD: /usr/bin/crash: unknown type [0x13] section `.relr.dyn'
> [/usr/bin/crash] error trace: 556181a34180 => 556181a331c5 =>
> 556181a76b10 => 556181b4adab
> BFD: /usr/bin/crash: unknown type [0x13] section `.relr.dyn'
>
> vtop: invalid structure member offset: dentry_d_iname
> FILE: filesys.c LINE: 3242 FUNCTION: get_pathname_component()
>
> crash>
>
> I replaced the field name to reflect the change on Linux kernel
> 6.14-rc1 and it seems to work without any errors, but I am not used to
> the crash code base and I didn't check the commit in
> details to make sure there aren't more issues affecting it. I'd say
>
No worries.
I will check the draft patch, and give you feedback later.
Thanks
Lianbo
there might be more changes needed to make sure crash works without
> errors on newer Linux kernel versions. The command I was using and
> resulted in error works fine now, but as I said, there might be
> more changes in order to really support the Linux kernel v6.14.
>
> $ sudo ./crash_modified/crash
> ~/work/kernels/packages/linux_upstream_6.14_rc1/vmlinux
>
> crash 8.0.6++
> Copyright (C) 2002-2025 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005, 2011, 2020-2024 NEC Corporation
> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> Copyright (C) 2015, 2021 VMware, Inc.
> This program is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for
> details.
>
> GNU gdb (GDB) 10.2
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> Type "show configuration" for configuration details.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
>
> KERNEL:
> /home/user/work/kernels/packages/linux_upstream_6.14_rc1/vmlinux
> DUMPFILE: /proc/kcore
> CPUS: 4
> DATE: Wed Dec 31 21:00:00 -03 1969
> UPTIME: 07:44:59
> LOAD AVERAGE: 0.40, 0.11, 0.03
> TASKS: 306
> NODENAME: fedoraserver41research
> RELEASE: 6.14.0-rc1
> VERSION: #1 SMP PREEMPT_DYNAMIC Wed Feb 12 00:07:46 -03 2025
> MACHINE: x86_64 (2995 Mhz)
> MEMORY: 2 GB
> PID: 47350
> COMMAND: "crash"
> TASK: ffff88801eeb8000 [THREAD_INFO: ffff88801eeb8000]
> CPU: 3
> STATE: TASK_RUNNING (ACTIVE)
>
> crash> vtop -c 1224 0x41400000
> VIRTUAL PHYSICAL
> 41400000 51144000
>
> PGD: 24438000 => dfaf067
> PUD: dfaf008 => 109fd067
> PMD: 109fd050 => fc07067
> PTE: fc07000 => 8000000051144867
> PAGE: 51144000
>
> PTE PHYSICAL FLAGS
> 8000000051144867 51144000 (PRESENT|RW|USER|ACCESSED|DIRTY|NX)
>
> VMA START END FLAGS FILE
> ffff888006b52b00 41400000 42800000 8100073
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffea0001445100 51144000 ffff88801440f361 41400 1 fffffd0020828
> uptodate,lru,owner_2,swapbacked
> crash> vtop -c 1224 7f058fbc2000
> VIRTUAL PHYSICAL
> 7f058fbc2000 3f278000
>
> PGD: 244387f0 => 8955067
> PUD: 89550b0 => 997b067
> PMD: 997b3e8 => 9b69067
> PTE: 9b69e10 => 800000003f278025
> PAGE: 3f278000
>
> PTE PHYSICAL FLAGS
> 800000003f278025 3f278000 (PRESENT|USER|ACCESSED|NX)
>
> VMA START END FLAGS FILE
> ffff88800ea17b00 7f058fbc2000 7f058fbc3000 8000071 /usr/lib64/libc.so.6
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> ffffea0000fc9e00 3f278000 ffff88800bf099c8 0 226 fffffe600426c
> referenced,uptodate,lru,workingset,private,head
> crash>
>
> The patch:
>
> $ git diff crash/filesys.c crash_modified/filesys.c
> diff --git a/crash/filesys.c b/crash_modified/filesys.c
> index 406ebb2..4759fa2 100644
> --- a/crash/filesys.c
> +++ b/crash_modified/filesys.c
> @@ -2050,7 +2050,7 @@ vfs_init(void)
> MEMBER_OFFSET_INIT(dentry_d_parent, "dentry", "d_parent");
> MEMBER_OFFSET_INIT(dentry_d_covers, "dentry", "d_covers");
> MEMBER_OFFSET_INIT(dentry_d_name, "dentry", "d_name");
> - MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_iname");
> + MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_shortname");
> MEMBER_OFFSET_INIT(dentry_d_sb, "dentry", "d_sb");
> MEMBER_OFFSET_INIT(inode_i_mode, "inode", "i_mode");
> MEMBER_OFFSET_INIT(inode_i_op, "inode", "i_op");
>
> Nevertheless, I am bringing this issue to the list for the people
> responsible for the crash development to implement the proper support
> for the Linux kernel v6.14. Thank you.
>
> Regards,
>
> Anderson Nascimento
> https://blog.andersonc0d3.io
>
3 weeks, 3 days
Crash errors when using vtop command on the Linux kernel v6.14-rc1
by Anderson Nascimento
Hello all,
I built the Linux kernel version 6.14-rc1 on Fedora 41 and the crash
utility doesn't
work as expected on it. Quickly investigating the issue, the commit below
from last month changes a field in the struct dentry and it seems to
be the reason for the errors I am seeing.
dcache: back inline names with a struct-wrapped array of unsigned long
https://github.com/torvalds/linux/commit/58cf9c383c5c686668082f83f7e0f3e0...
The errors are the following:
crash> vtop -c 1224 0x41400000
VIRTUAL PHYSICAL
41400000 51144000
PGD: 24438000 => dfaf067
PUD: dfaf008 => 109fd067
PMD: 109fd050 => fc07067
PTE: fc07000 => 8000000051144867
PAGE: 51144000
PTE PHYSICAL FLAGS
8000000051144867 51144000 (PRESENT|RW|USER|ACCESSED|DIRTY|NX)
VMA START END FLAGS FILE
vtop: invalid structure member offset: dentry_d_iname
FILE: filesys.c LINE: 3242 FUNCTION: get_pathname_component()
BFD: /usr/bin/crash: unknown type [0x13] section `.relr.dyn'
[/usr/bin/crash] error trace: 556181a34180 => 556181a331c5 =>
556181a76b10 => 556181b4adab
BFD: /usr/bin/crash: unknown type [0x13] section `.relr.dyn'
vtop: invalid structure member offset: dentry_d_iname
FILE: filesys.c LINE: 3242 FUNCTION: get_pathname_component()
crash>
I replaced the field name to reflect the change on Linux kernel
6.14-rc1 and it seems to work without any errors, but I am not used to
the crash code base and I didn't check the commit in
details to make sure there aren't more issues affecting it. I'd say
there might be more changes needed to make sure crash works without
errors on newer Linux kernel versions. The command I was using and
resulted in error works fine now, but as I said, there might be
more changes in order to really support the Linux kernel v6.14.
$ sudo ./crash_modified/crash
~/work/kernels/packages/linux_upstream_6.14_rc1/vmlinux
crash 8.0.6++
Copyright (C) 2002-2025 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2024 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
KERNEL: /home/user/work/kernels/packages/linux_upstream_6.14_rc1/vmlinux
DUMPFILE: /proc/kcore
CPUS: 4
DATE: Wed Dec 31 21:00:00 -03 1969
UPTIME: 07:44:59
LOAD AVERAGE: 0.40, 0.11, 0.03
TASKS: 306
NODENAME: fedoraserver41research
RELEASE: 6.14.0-rc1
VERSION: #1 SMP PREEMPT_DYNAMIC Wed Feb 12 00:07:46 -03 2025
MACHINE: x86_64 (2995 Mhz)
MEMORY: 2 GB
PID: 47350
COMMAND: "crash"
TASK: ffff88801eeb8000 [THREAD_INFO: ffff88801eeb8000]
CPU: 3
STATE: TASK_RUNNING (ACTIVE)
crash> vtop -c 1224 0x41400000
VIRTUAL PHYSICAL
41400000 51144000
PGD: 24438000 => dfaf067
PUD: dfaf008 => 109fd067
PMD: 109fd050 => fc07067
PTE: fc07000 => 8000000051144867
PAGE: 51144000
PTE PHYSICAL FLAGS
8000000051144867 51144000 (PRESENT|RW|USER|ACCESSED|DIRTY|NX)
VMA START END FLAGS FILE
ffff888006b52b00 41400000 42800000 8100073
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0001445100 51144000 ffff88801440f361 41400 1 fffffd0020828
uptodate,lru,owner_2,swapbacked
crash> vtop -c 1224 7f058fbc2000
VIRTUAL PHYSICAL
7f058fbc2000 3f278000
PGD: 244387f0 => 8955067
PUD: 89550b0 => 997b067
PMD: 997b3e8 => 9b69067
PTE: 9b69e10 => 800000003f278025
PAGE: 3f278000
PTE PHYSICAL FLAGS
800000003f278025 3f278000 (PRESENT|USER|ACCESSED|NX)
VMA START END FLAGS FILE
ffff88800ea17b00 7f058fbc2000 7f058fbc3000 8000071 /usr/lib64/libc.so.6
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0000fc9e00 3f278000 ffff88800bf099c8 0 226 fffffe600426c
referenced,uptodate,lru,workingset,private,head
crash>
The patch:
$ git diff crash/filesys.c crash_modified/filesys.c
diff --git a/crash/filesys.c b/crash_modified/filesys.c
index 406ebb2..4759fa2 100644
--- a/crash/filesys.c
+++ b/crash_modified/filesys.c
@@ -2050,7 +2050,7 @@ vfs_init(void)
MEMBER_OFFSET_INIT(dentry_d_parent, "dentry", "d_parent");
MEMBER_OFFSET_INIT(dentry_d_covers, "dentry", "d_covers");
MEMBER_OFFSET_INIT(dentry_d_name, "dentry", "d_name");
- MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_iname");
+ MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_shortname");
MEMBER_OFFSET_INIT(dentry_d_sb, "dentry", "d_sb");
MEMBER_OFFSET_INIT(inode_i_mode, "inode", "i_mode");
MEMBER_OFFSET_INIT(inode_i_op, "inode", "i_op");
Nevertheless, I am bringing this issue to the list for the people
responsible for the crash development to implement the proper support
for the Linux kernel v6.14. Thank you.
Regards,
Anderson Nascimento
https://blog.andersonc0d3.io
3 weeks, 5 days
Crash errors when using vtop command on the 6.14-rc1 kernel
by Allele Security Intelligence
Hello all,
I built the kernel 6.14-rc1 on Fedora 41 and the crash utility doesn't
work as expected. Quickly investigating the issue, the commit below
from last month changes a field in the struct dentry and it seems to
be the reason for the errors I am seeing.
dcache: back inline names with a struct-wrapped array of unsigned long
https://github.com/torvalds/linux/commit/58cf9c383c5c686668082f83f7e0f3e0...
The error is the following:
crash> vtop -c 1224 0x41400000
VIRTUAL PHYSICAL
41400000 51144000
PGD: 24438000 => dfaf067
PUD: dfaf008 => 109fd067
PMD: 109fd050 => fc07067
PTE: fc07000 => 8000000051144867
PAGE: 51144000
PTE PHYSICAL FLAGS
8000000051144867 51144000 (PRESENT|RW|USER|ACCESSED|DIRTY|NX)
VMA START END FLAGS FILE
vtop: invalid structure member offset: dentry_d_iname
FILE: filesys.c LINE: 3242 FUNCTION: get_pathname_component()
BFD: /usr/bin/crash: unknown type [0x13] section `.relr.dyn'
[/usr/bin/crash] error trace: 556181a34180 => 556181a331c5 =>
556181a76b10 => 556181b4adab
BFD: /usr/bin/crash: unknown type [0x13] section `.relr.dyn'
vtop: invalid structure member offset: dentry_d_iname
FILE: filesys.c LINE: 3242 FUNCTION: get_pathname_component()
crash>
I changed the field name and it seems to work now without errors, but
I don't know the crash source code and didn't check the commit in
details or even other ones applied to 6.14-rc1 to make sure there's
not more problems for crash. I'd say there might be more changes to be
done to really fix the potential issues. The command I was using and
resulted in error works just fine now, but as I said, there might be
more changes in order to really support the 6.14 kernel.
$ sudo ./crash_modified/crash
~/work/kernels/packages/linux_upstream_6.14_rc1/vmlinux
crash 8.0.6++
Copyright (C) 2002-2025 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2024 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
KERNEL: /home/user/work/kernels/packages/linux_upstream_6.14_rc1/vmlinux
DUMPFILE: /proc/kcore
CPUS: 4
DATE: Wed Dec 31 21:00:00 -03 1969
UPTIME: 07:44:59
LOAD AVERAGE: 0.40, 0.11, 0.03
TASKS: 306
NODENAME: fedoraserver41research
RELEASE: 6.14.0-rc1
VERSION: #1 SMP PREEMPT_DYNAMIC Wed Feb 12 00:07:46 -03 2025
MACHINE: x86_64 (2995 Mhz)
MEMORY: 2 GB
PID: 47350
COMMAND: "crash"
TASK: ffff88801eeb8000 [THREAD_INFO: ffff88801eeb8000]
CPU: 3
STATE: TASK_RUNNING (ACTIVE)
crash> vtop -c 1224 0x41400000
VIRTUAL PHYSICAL
41400000 51144000
PGD: 24438000 => dfaf067
PUD: dfaf008 => 109fd067
PMD: 109fd050 => fc07067
PTE: fc07000 => 8000000051144867
PAGE: 51144000
PTE PHYSICAL FLAGS
8000000051144867 51144000 (PRESENT|RW|USER|ACCESSED|DIRTY|NX)
VMA START END FLAGS FILE
ffff888006b52b00 41400000 42800000 8100073
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0001445100 51144000 ffff88801440f361 41400 1 fffffd0020828
uptodate,lru,owner_2,swapbacked
crash> vtop -c 1224 7f058fbc2000
VIRTUAL PHYSICAL
7f058fbc2000 3f278000
PGD: 244387f0 => 8955067
PUD: 89550b0 => 997b067
PMD: 997b3e8 => 9b69067
PTE: 9b69e10 => 800000003f278025
PAGE: 3f278000
PTE PHYSICAL FLAGS
800000003f278025 3f278000 (PRESENT|USER|ACCESSED|NX)
VMA START END FLAGS FILE
ffff88800ea17b00 7f058fbc2000 7f058fbc3000 8000071 /usr/lib64/libc.so.6
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0000fc9e00 3f278000 ffff88800bf099c8 0 226 fffffe600426c
referenced,uptodate,lru,workingset,private,head
crash>
The patch:
$ git diff crash/filesys.c crash_modified/filesys.c
diff --git a/crash/filesys.c b/crash_modified/filesys.c
index 406ebb2..4759fa2 100644
--- a/crash/filesys.c
+++ b/crash_modified/filesys.c
@@ -2050,7 +2050,7 @@ vfs_init(void)
MEMBER_OFFSET_INIT(dentry_d_parent, "dentry", "d_parent");
MEMBER_OFFSET_INIT(dentry_d_covers, "dentry", "d_covers");
MEMBER_OFFSET_INIT(dentry_d_name, "dentry", "d_name");
- MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_iname");
+ MEMBER_OFFSET_INIT(dentry_d_iname, "dentry", "d_shortname");
MEMBER_OFFSET_INIT(dentry_d_sb, "dentry", "d_sb");
MEMBER_OFFSET_INIT(inode_i_mode, "inode", "i_mode");
MEMBER_OFFSET_INIT(inode_i_op, "inode", "i_op");
Anyway, I am bringing this issue to the list so you people can
properly implement support for the 6.14 kernel. Thank you!
Anderson Nascimento
4 weeks, 1 day
[PATCH v2 0/3] Update to gdb-16.2
by Tao Liu
v2 -> v1: Splite the "Fix several build failures" patchset, which is
already merged btw, from gdb v16.2 upgrading.
Tao Liu (3):
LoongArch64: Revert all previous LoongArch64 related commits
Revert: Fix C99 compatibility issues in embedded copy of GDB
Update to gdb-16.2
Makefile | 10 +-
README | 6 +-
configure.c | 64 +-
crash.8 | 2 +-
crash_target.c | 6 +-
defs.h | 174 +-
diskdump.c | 24 +-
gdb-10.2.patch | 16323 ------------------------------------------
gdb-16.2.patch | 2254 ++++++
gdb_interface.c | 14 +-
help.c | 15 +-
kernel.c | 6 +-
lkcd_vmdump_v1.h | 2 +-
lkcd_vmdump_v2_v3.h | 5 +-
loongarch64.c | 1368 ----
main.c | 3 +-
netdump.c | 27 +-
ramdump.c | 2 -
symbols.c | 37 +-
19 files changed, 2322 insertions(+), 18020 deletions(-)
delete mode 100644 gdb-10.2.patch
create mode 100644 gdb-16.2.patch
delete mode 100644 loongarch64.c
--
2.47.0
1 month, 1 week