[PATCH] arm64: use TCR_EL1_T1SZ to get the correct info if vabits_actual is missing
by Huang Shijie
After kernel patch:
"0d9b1ffefabe arm64: mm: make vabits_actual a build time constant if possible"
the "vabits_actual" is not compiled to kernel symbols when "VA_BITS > 48"
is false.
So the crash will not find the "vabits_actual" symbol, and it will
fail in the end.
This patch introduces the arm64_set_va_bits_by_tcr(), and if crash cannot
find "vabits_actual" symbol, it will use the TCR_EL1_T1SZ register to get
the correct VA_BITS_ACTUAL/VA_BITS/VA_START.
Tested this patch with:
1.) the live mode with /proc/kcore
2.) the kdump file with /proc/vmcore.
Signed-off-by: Huang Shijie <shijie(a)os.amperecomputing.com>
---
arm64.c | 50 +++++++++++++++++++++++++++++++++-----------------
1 file changed, 33 insertions(+), 17 deletions(-)
diff --git a/arm64.c b/arm64.c
index b6b7aa1..3a613f9 100644
--- a/arm64.c
+++ b/arm64.c
@@ -4586,6 +4586,35 @@ arm64_IS_VMALLOC_ADDR(ulong vaddr)
(vaddr >= ms->modules_vaddr && vaddr <= ms->modules_end));
}
+/* Return TRUE if we succeed, return FALSE on failure. */
+static int arm64_set_va_bits_by_tcr()
+{
+ ulong value;
+ char *string;
+
+ if ((string = pc->read_vmcoreinfo("NUMBER(TCR_EL1_T1SZ)")) ||
+ (string = pc->read_vmcoreinfo("NUMBER(tcr_el1_t1sz)"))) {
+ /* See ARMv8 ARM for the description of
+ * TCR_EL1.T1SZ and how it can be used
+ * to calculate the vabits_actual
+ * supported by underlying kernel.
+ *
+ * Basically:
+ * vabits_actual = 64 - T1SZ;
+ */
+ value = 64 - strtoll(string, NULL, 0);
+ if (CRASHDEBUG(1))
+ fprintf(fp, "vmcoreinfo : vabits_actual: %ld\n", value);
+ free(string);
+ machdep->machspec->VA_BITS_ACTUAL = value;
+ machdep->machspec->VA_BITS = value;
+ machdep->machspec->VA_START = _VA_START(machdep->machspec->VA_BITS_ACTUAL);
+ return TRUE;
+ }
+
+ return FALSE;
+}
+
static void
arm64_calc_VA_BITS(void)
{
@@ -4616,23 +4645,8 @@ arm64_calc_VA_BITS(void)
} else if (ACTIVE())
error(FATAL, "cannot determine VA_BITS_ACTUAL: please use /proc/kcore\n");
else {
- if ((string = pc->read_vmcoreinfo("NUMBER(TCR_EL1_T1SZ)")) ||
- (string = pc->read_vmcoreinfo("NUMBER(tcr_el1_t1sz)"))) {
- /* See ARMv8 ARM for the description of
- * TCR_EL1.T1SZ and how it can be used
- * to calculate the vabits_actual
- * supported by underlying kernel.
- *
- * Basically:
- * vabits_actual = 64 - T1SZ;
- */
- value = 64 - strtoll(string, NULL, 0);
- if (CRASHDEBUG(1))
- fprintf(fp, "vmcoreinfo : vabits_actual: %ld\n", value);
- free(string);
- machdep->machspec->VA_BITS_ACTUAL = value;
- machdep->machspec->VA_BITS = value;
- machdep->machspec->VA_START = _VA_START(machdep->machspec->VA_BITS_ACTUAL);
+ if (arm64_set_va_bits_by_tcr()) {
+ /* nothing */
} else if (machdep->machspec->VA_BITS_ACTUAL) {
machdep->machspec->VA_BITS = machdep->machspec->VA_BITS_ACTUAL;
machdep->machspec->VA_START = _VA_START(machdep->machspec->VA_BITS_ACTUAL);
@@ -4654,6 +4668,8 @@ arm64_calc_VA_BITS(void)
*/
machdep->flags |= FLIPPED_VM;
return;
+ } else if (arm64_set_va_bits_by_tcr()) {
+ return;
}
if (!(sp = symbol_search("swapper_pg_dir")) &&
--
2.30.2
2 years
[PATCH] Fix kmem failing to print task context when address is vmalloced stack
by Tao Liu
When kernel enabled CONFIG_VMAP_STACK, stack can be allocated to
vmalloced area. Currently crash didn't handle the case, as a result,
kmem will not print the task context as expected. This patch fix the
bug by checking if the address is a vmalloced stack first.
Before:
crash> kmem ffffb7efce9bbe28
VMAP_AREA VM_STRUCT ADDRESS RANGE SIZE
ffff94eb9102c640 ffff94eb9102b140 ffffb7efce9b8000 - ffffb7efce9bd000 20480
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
After:
crash> kmem ffffb7efce9bbe28
PID: 847
COMMAND: "khungtaskd"
TASK: ffff94f8038f4000 [THREAD_INFO: ffff94f8038f4000]
CPU: 72
STATE: TASK_RUNNING (PANIC)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffdd28220dc000 1883700000 0 0 1 50000000000000
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
memory.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/memory.c b/memory.c
index 7339f0c..7a1bf9c 100644
--- a/memory.c
+++ b/memory.c
@@ -13477,6 +13477,11 @@ kmem_search(struct meminfo *mi)
* Check for a valid mapped address.
*/
if ((mi->memtype == KVADDR) && IS_VMALLOC_ADDR(mi->spec_addr)) {
+ if ((task = stkptr_to_task(vaddr)) && (tc = task_to_context(task))) {
+ show_context(tc);
+ fprintf(fp, "\n");
+ goto mem_map;
+ }
if (kvtop(NULL, mi->spec_addr, &paddr, 0)) {
mi->flags = orig_flags | VMLIST_VERIFY;
dump_vmlist(mi);
--
2.33.1
2 years
[PATCH] Add ending identifier for task structure parsing
by Tao Liu
Previously, the ending identifier for parsing the task structure
member is " }, \n". However the ending identifier is not always
as expected. " },\n" can also be the ending identifier. For example,
if we have the following struct, the parsing will fail.
tasks = {\n
next = 0xffff94f8038f8838,\n
prev = 0xffff94f8036f8838\n
},\n
Before:
crash> task -R tasks ffff94f8038f4000
PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND: "khungtaskd"
After:
crash> task -R tasks ffff94f8038f4000
PID: 847 TASK: ffff94f8038f4000 CPU: 72 COMMAND: "khungtaskd"
tasks = {
next = 0xffff94f8038f8838,
prev = 0xffff94f8036f8838
},
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
task.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/task.c b/task.c
index 071c787..db2abc8 100644
--- a/task.c
+++ b/task.c
@@ -3436,7 +3436,8 @@ parse_task_thread(int argcnt, char *arglist[], struct task_context *tc) {
while (fgets(buf, BUFSIZE, pc->tmpfile)) {
if (STREQ(buf, " {\n"))
randomized = TRUE;
- else if (randomized && STREQ(buf, " }, \n"))
+ else if (randomized &&
+ (STREQ(buf, " }, \n") || STREQ(buf, " },\n")))
randomized = FALSE;
if (strlen(lookfor2)) {
--
2.33.1
2 years
[PATCH 1/2] Let gdb get kernel module symbols info from crash
by Tao Liu
Gdb will try to resolve an address to its corresponding symbol name such as
when printing a structure. It works fine for kernel symbols, because gdb can
find them through vmlinux. However as for kernel modules symbols, crash
resolves them by dig into "struct module", which gdb don't know. As a
results, gdb fails to translate an kernel modules address to it's symbolic
name. For example we can reproduce the issue as follows.
crash> timer
....
4331308176 336 ffff94ea24240860 ffffffffc03762c0 <estimation_timer>
....
crash> sym 0xffffffffc03762c0
ffffffffc03762c0 (t) estimation_timer [ip_vs]
Before patch:
crash> timer_list ffff94ea24240860
struct timer_list {
....
function = 0xffffffffc03762c0,
....
}
After patch:
crash> timer_list ffff94ea24240860
struct timer_list {
....
function = 0xffffffffc03762c0 <estimation_timer>,
....
}
In this patch, we add an interface for gdb, when gdb trying to build kernel
module's address symbolic, the info can be get from crash.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
defs.h | 2 ++
gdb-10.2.patch | 35 +++++++++++++++++++++++++++++++++--
gdb_interface.c | 12 ++++++++++++
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/defs.h b/defs.h
index 9d6d891..afdcf6c 100644
--- a/defs.h
+++ b/defs.h
@@ -4874,6 +4874,7 @@ extern "C" int patch_kernel_symbol(struct gnu_request *);
struct syment *symbol_search(char *);
int gdb_line_number_callback(ulong, ulong, ulong);
int gdb_print_callback(ulong);
+char *gdb_lookup_module_symbol(ulong, ulong *);
extern "C" int same_file(char *, char *);
#endif
@@ -7284,6 +7285,7 @@ int gdb_pass_through(char *, FILE *, ulong);
int gdb_readmem_callback(ulong, void *, int, int);
int gdb_line_number_callback(ulong, ulong, ulong);
int gdb_print_callback(ulong);
+char *gdb_lookup_module_symbol(ulong, ulong *);
void gdb_error_hook(void);
void restore_gdb_sanity(void);
int is_gdb_command(int, ulong);
diff --git a/gdb-10.2.patch b/gdb-10.2.patch
index f0034ed..d08e9ab 100644
--- a/gdb-10.2.patch
+++ b/gdb-10.2.patch
@@ -399,7 +399,38 @@ exit 0
if (build_address_symbolic (gdbarch, addr, do_demangle, false, &name,
&offset, &filename, &line, &unmapped))
return 0;
-@@ -1221,6 +1230,43 @@ print_command_1 (const char *args, int voidprint)
+@@ -567,6 +576,10 @@ print_address_symbolic (struct gdbarch *gdbarch, CORE_ADDR addr,
+
+ /* See valprint.h. */
+
++#ifdef CRASH_MERGE
++extern "C" char *gdb_lookup_module_symbol(unsigned long, unsigned long *);
++#endif
++
+ int
+ build_address_symbolic (struct gdbarch *gdbarch,
+ CORE_ADDR addr, /* IN */
+@@ -673,7 +686,19 @@ build_address_symbolic (struct gdbarch *gdbarch,
+ }
+ }
+ if (symbol == NULL && msymbol.minsym == NULL)
++#ifdef CRASH_MERGE
++ {
++ char *name_ptr = gdb_lookup_module_symbol(addr, (unsigned long *)offset);
++ if (name_ptr) {
++ *name = name_ptr;
++ return 0;
++ } else {
++ return 1;
++ }
++ }
++#else
+ return 1;
++#endif
+
+ /* If the nearest symbol is too far away, don't print anything symbolic. */
+
+@@ -1221,6 +1246,43 @@ print_command_1 (const char *args, int voidprint)
print_value (val, print_opts);
}
@@ -443,7 +474,7 @@ exit 0
/* See valprint.h. */
void
-@@ -2855,6 +2901,12 @@ but no count or size letter (see \"x\" command)."),
+@@ -2855,6 +2917,12 @@ but no count or size letter (see \"x\" command)."),
c = add_com ("print", class_vars, print_command, print_help.c_str ());
set_cmd_completer_handle_brkchars (c, print_command_completer);
add_com_alias ("p", "print", class_vars, 1);
diff --git a/gdb_interface.c b/gdb_interface.c
index 3a7fcc9..b14319c 100644
--- a/gdb_interface.c
+++ b/gdb_interface.c
@@ -935,6 +935,18 @@ gdb_print_callback(ulong addr)
return IS_KVADDR(addr);
}
+char *
+gdb_lookup_module_symbol(ulong addr, ulong *offset)
+{
+ struct syment *sp;
+
+ if ((sp = value_search_module(addr, offset))) {
+ return sp->name;
+ } else {
+ return NULL;
+ }
+}
+
/*
* Used by gdb_interface() to catch gdb-related errors, if desired.
*/
--
2.33.1
2 years
[PATCH v2] gdb: fix for assigning NULL to std::string
by Lianbo Jiang
When trying to load a module with "mod -s" without its separated debug
info file installed, the crash utility will abort as below:
crash> mod -s kpatch_test kpatch_test.ko
...
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Aborted (core dumped)
Let's return the std::string() instead of std::string(NULL) when a
string is null, because the check_specified_kernel_debug_file() may
return NULL.
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
gdb-10.2.patch | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/gdb-10.2.patch b/gdb-10.2.patch
index 577f5e45fc5a..f0034ed626a0 100644
--- a/gdb-10.2.patch
+++ b/gdb-10.2.patch
@@ -9,6 +9,7 @@
# to all subsequent patch applications.
tar xvzmf gdb-10.2.tar.gz \
+ gdb-10.2/gdb/symfile.c \
gdb-10.2/gdb/Makefile.in
exit 0
@@ -1650,3 +1651,13 @@ exit 0
c_print_type_1 (type->field (i).type (),
TYPE_FIELD_NAME (type, i),
+--- gdb-10.2/gdb/symfile.c.orig
++++ gdb-10.2/gdb/symfile.c
+@@ -1610,7 +1610,7 @@ find_separate_debug_file_by_debuglink (struct objfile *objfile)
+ if (debugfile.empty ()) {
+ char *name_copy;
+ name_copy = check_specified_kernel_debug_file();
+- return std::string (name_copy);
++ return name_copy ? std::string (name_copy) : std::string ();
+ }
+ #endif
--
2.37.1
2 years
[PATCH] gdb: fix for assigning NULL to std::string
by Lianbo Jiang
When the lack of debuginfo package, try to load its module with the "mod
-s xxx" in crash, it will cause the crash utility coredump as below:
crash> mod -s kpatch_test kpatch_test.ko
...
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Aborted (core dumped)
Let's return the std::string() instead of std::string(NULL) when a
string is null, because the check_specified_kernel_debug_file() may
return NULL.
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=<optimized out>, no_tid=<optimized out>) at pthread_kill.c:44
#1 0x00007fff8b48223c in __GI_raise (sig=<optimized out>) at ../sysdeps/posix/raise.c:26
#2 0x00007fff8b45c70c in __GI_abort () at abort.c:79
#3 0x00007fff8b8cbee8 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#4 0x00007fff8b8c74e4 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#5 0x00007fff8b8c75b0 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
#6 0x00007fff8b8c7a94 in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0x7fff8bac48b0 <typeinfo for std::logic_error>, dest=0x7fff8b8e93d0 <std::logic_error::~logic_error()>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:95
#7 0x00007fff8b889370 in std::__throw_logic_error (__s=0x1312445d0 "basic_string::_M_construct null not valid") at ../../../../../libstdc++-v3/src/c++11/functexcept.cc:70
#8 0x000000013105d448 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag) [clone .constprop.0] (this=0x7fffdde41128, __beg=<optimized out>, __end=<optimized out>) at /usr/include/c++/11/bits/basic_string.tcc:212
#9 0x0000000130da805c in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<std::allocator<char> > (__a=..., __s=<optimized out>, this=0x7fffdde41128) at /usr/include/c++/11/bits/basic_string.h:539
#10 find_separate_debug_file_by_debuglink[abi:cxx11](objfile*) (objfile=<optimized out>) at symfile.c:1613
#11 0x0000000130b41028 in elf_symfile_read (objfile=0x1003ccd5bb0, symfile_flags=...) at elfread.c:1304
#12 0x0000000130da68b8 in read_symbols (objfile=<optimized out>, objfile@entry=0x1003ccd5bb0, add_flags=..., add_flags@entry=...) at symfile.c:800
#13 0x0000000130da5f48 in syms_from_objfile_1 (add_flags=..., addrs=0x7fffdde41450, objfile=0x1003ccd5bb0) at symfile.c:997
#14 syms_from_objfile (add_flags=..., addrs=0x7fffdde41450, objfile=0x1003ccd5bb0) at symfile.c:1014
#15 symbol_file_add_with_addrs (abfd=<optimized out>, name=name@entry=0x1003db636a0 "kpatch_test.ko", add_flags=add_flags@entry=..., addrs=addrs@entry=0x7fffdde41450, flags=..., flags@entry=..., parent=parent@entry=0x0) at symfile.c:1123
#16 0x0000000130da86e8 in symbol_file_add_from_bfd (parent=0x0, flags=..., addrs=0x7fffdde41450, add_flags=..., name=0x1003db636a0 "kpatch_test.ko", abfd=<optimized out>) at symfile.c:1204
#17 symbol_file_add (name=0x1003db636a0 "kpatch_test.ko", add_flags=..., addrs=0x7fffdde41450, flags=...) at symfile.c:1217
#18 0x0000000130dade4c in add_symbol_file_command (args=<optimized out>, from_tty=<optimized out>) at symfile.c:2388
#19 0x0000000130a3e04c in do_const_cfunc (c=<optimized out>, args=<optimized out>, from_tty=<optimized out>) at cli/cli-decode.c:95
#20 0x0000000130a40c48 in cmd_func (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>) at cli/cli-decode.c:2181
#21 0x0000000130e2344c in execute_command (p=<optimized out>, from_tty=<optimized out>) at top.c:668
#22 0x0000000130dc9d9c in gdb_add_symbol_file (req=0x7fffdde41b10) at symtab.c:7436
#23 gdb_command_funnel_1 (req=req@entry=0x7fffdde41b10) at symtab.c:7004
#24 0x0000000130dcaa40 in gdb_command_funnel (req=0x7fffdde41b10) at symtab.c:6954
#25 0x00000001308c78ec in gdb_interface (req=0x7fffdde41b10) at ../../gdb_interface.c:409
#26 0x0000000130942adc in add_symbol_file (lm=0x1003ff62098) at ../../symbols.c:11914
#27 0x00000001309442a0 in load_module_symbols (modref=<optimized out>, namelist=0x13146b682 <program_context+258> "kpatch_test.ko", base_addr=13837309855101681664) at ../../symbols.c:11852
#28 0x000000013089f7b0 in do_module_cmd (flag=3, modref=<optimized out>, address=<optimized out>, objfile=<optimized out>, tree=<optimized out>) at ../../kernel.c:4602
#29 0x000000013089da6c in cmd_mod () at ../../kernel.c:4204
#30 0x00000001307e27bc in exec_command () at ../../main.c:892
#31 0x000000013094d004 in exec_input_file () at ../../cmdline.c:1489
#32 0x00000001307e2214 in is_input_file () at ../../main.c:988
#33 exec_command () at ../../main.c:899
#34 0x00000001307e2bbc in main_loop () at ../../main.c:839
#35 0x0000000130c30654 in captured_main (data=<optimized out>) at main.c:1284
#36 gdb_main (args=<optimized out>) at main.c:1313
#37 0x00000001308c5fbc in gdb_main_entry (argv=0x7fffdde45ca8, argc=2) at main.c:1338
#38 gdb_main_loop (argc=2, argv=0x7fffdde45ca8) at ../../gdb_interface.c:81
#39 0x00000001307d1158 in main (argc=<optimized out>, argv=0x7fffdde45ca8) at ../../main.c:720
(gdb)
gdb-10.2.patch | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/gdb-10.2.patch b/gdb-10.2.patch
index 577f5e45fc5a..3e0569d8ea98 100644
--- a/gdb-10.2.patch
+++ b/gdb-10.2.patch
@@ -1650,3 +1650,13 @@ exit 0
c_print_type_1 (type->field (i).type (),
TYPE_FIELD_NAME (type, i),
+--- gdb-10.2/gdb/symfile.c.orig
++++ gdb-10.2/gdb/symfile.c
+@@ -1610,7 +1610,7 @@ find_separate_debug_file_by_debuglink (struct objfile *objfile)
+ if (debugfile.empty ()) {
+ char *name_copy;
+ name_copy = check_specified_kernel_debug_file();
+- return std::string (name_copy);
++ return name_copy ? std::string (name_copy) : std::string ();
+ }
+ #endif
--
2.35.1
2 years
[PATCH v2] Makefile: Fix unnecessary re-patching with coreutils-9.0
by HAGIO KAZUHITO(萩尾 一仁)
"sum" command in coreutils-9.0 (e.g. Fedora 36) started to output a file
name. As a result, "make" always detects a change of gdb-10.2.patch
wrongly and re-applies it unnecessarily.
Use standard input to fix it and "md5sum" to improve detection.
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 162c2ba..79aef17 100644
--- a/Makefile
+++ b/Makefile
@@ -272,7 +272,7 @@ rebuild:
@if [ ! -f ${GDB}/${GDB}.patch ]; then \
touch ${GDB}/${GDB}.patch; fi
@if [ -f ${GDB}.patch ] && [ -s ${GDB}.patch ] && \
- [ "`sum ${GDB}.patch`" != "`sum ${GDB}/${GDB}.patch`" ]; then \
+ [ "`md5sum < ${GDB}.patch`" != "`md5sum < ${GDB}/${GDB}.patch`" ]; then \
(sh -x ${GDB}.patch ${TARGET}; patch -N -p0 -r- --fuzz=0 < ${GDB}.patch; cp ${GDB}.patch ${GDB}; cd ${GDB}; \
$(MAKE) CRASH_TARGET=${TARGET}) \
else (cd ${GDB}/gdb; $(MAKE) CRASH_TARGET=${TARGET}); fi
--
2.37.1
2 years
[PATCH] Makefile: Fix unnecessary re-patching with coreutils-9.0
by HAGIO KAZUHITO(萩尾 一仁)
"sum" command in coreutils-9.0 (e.g. Fedora 36) started to output a file
name. As a result, "make" always detects a change of gdb-10.2.patch
wrongly and re-applies it unnecessarily.
Use "cmp" command instead.
Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 162c2baa5164..020fc8207277 100644
--- a/Makefile
+++ b/Makefile
@@ -272,7 +272,7 @@ rebuild:
@if [ ! -f ${GDB}/${GDB}.patch ]; then \
touch ${GDB}/${GDB}.patch; fi
@if [ -f ${GDB}.patch ] && [ -s ${GDB}.patch ] && \
- [ "`sum ${GDB}.patch`" != "`sum ${GDB}/${GDB}.patch`" ]; then \
+ ! cmp -s ${GDB}.patch ${GDB}/${GDB}.patch; then \
(sh -x ${GDB}.patch ${TARGET}; patch -N -p0 -r- --fuzz=0 < ${GDB}.patch; cp ${GDB}.patch ${GDB}; cd ${GDB}; \
$(MAKE) CRASH_TARGET=${TARGET}) \
else (cd ${GDB}/gdb; $(MAKE) CRASH_TARGET=${TARGET}); fi
--
2.31.1
2 years
[PATCH V5 0/6] RISC-V fixups to work with crash tool
by Xianting Tian
I ever sent the patch 1 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
And patch 2,3 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This patch set just put these patches together, and with three new patch 4, 5, 6.
these six patches are the fixups for machine_kexec, kernel mode PC for vmcore
and improvements for vmcoreinfo, memory layout dump and fixup chedule out issue
in machine_crash_shutdown().
The main changes in the six patchs as below,
Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
the console prints.
Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
Patch 3: Add modules to virtual kernel memory layout dump.
Patch 4: Fixup to get correct kernel mode PC for vmcore.
Patch 5: Updates vmcoreinfo.rst.
Patch 6: Fixup schedule out issue in machine_crash_shutdown()
With these six patches(patch 2 is must), crash tool can work well to analyze
a vmcore. The patches for crash tool for RISCV64 is in the link:
https://lore.kernel.org/linux-riscv/20220801043040.2003264-1-xianting.tia...
------
Changes v1 -> v2:
1, remove the patch "Add a fast call path of crash_kexec()" from this series
of patches, as it already applied to riscv git.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
2, add 'Reviewed-by' based on the comments of v1.
Changes v2 -> v3:
use "riscv" instead of "riscv64" in patch 5 subject line.
Changes v3 -> v4:
use "riscv" instead of "riscv64" in the summary of patch 5 subject line.
Changes v4 -> v5:
add a new patch "RISC-V: Fixup schedule out issue in machine_crash_shutdown()"
Xianting Tian (6):
RISC-V: use __smp_processor_id() instead of smp_processor_id()
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
RISC-V: Fixup getting correct current pc
riscv: crash_core: Export kernel vm layout, phys_ram_base
RISC-V: Fixup schedule out issue in machine_crash_shutdown()
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
arch/riscv/kernel/crash_save_regs.S | 2 +-
arch/riscv/kernel/machine_kexec.c | 28 ++++++++++++++---
arch/riscv/mm/init.c | 4 +++
6 files changed, 89 insertions(+), 6 deletions(-)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
2 years
[PATCH V2 0/9] Support RISCV64 arch and common commands
by Xianting Tian
This series of patches are for Crash-utility tool, it make crash tool support
RISCV64 arch and the common commands(*, bt, p, rd, mod, log, set, struct, task,
dis, help -r, help -m, and so on).
To make the crash tool work normally for RISCV64 arch, we need a Linux kernel
patch(wait for apply), which exports the kernel virtual memory layout, va_bits,
phys_ram_base to vmcoreinfo, it can simplify the development of crash tool.
The Linux kernel patch set:
https://lore.kernel.org/linux-riscv/20220726093729.1231867-1-xianting.tia...
This series of patches are tested on QEMU RISCV64 env and SoC platform of
T-head Xuantie 910 RISCV64 CPU.
====================================
Some test examples list as below
====================================
... ...
KERNEL: vmlinux
DUMPFILE: vmcore
CPUS: 1
DATE: Fri Jul 15 10:24:25 CST 2022
UPTIME: 00:00:33
LOAD AVERAGE: 0.05, 0.01, 0.00
TASKS: 41
NODENAME: buildroot
RELEASE: 5.18.9
VERSION: #30 SMP Fri Jul 15 09:47:03 CST 2022
MACHINE: riscv64 (unknown Mhz)
MEMORY: 1 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 113
COMMAND: "sh"
TASK: ff60000002269600 [THREAD_INFO: ff60000002269600]
CPU: 0
STATE: TASK_RUNNING (PANIC)
carsh>
crash> p mem_map
mem_map = $1 = (struct page *) 0xff6000003effbf00
crash> p /x *(struct page *) 0xff6000003effbf00
$5 = {
flags = 0x1000,
{
{
{
lru = {
next = 0xff6000003effbf08,
prev = 0xff6000003effbf08
},
{
__filler = 0xff6000003effbf08,
mlock_count = 0x3effbf08
}
},
mapping = 0x0,
index = 0x0,
private = 0x0
},
... ...
crash> mod
MODULE NAME BASE SIZE OBJECT FILE
ffffffff0113e740 nvme_core ffffffff01133000 98304 (not loaded) [CONFIG_KALLSYMS]
ffffffff011542c0 nvme ffffffff0114c000 61440 (not loaded) [CONFIG_KALLSYMS]
crash> rd ffffffff0113e740 8
ffffffff0113e740: 0000000000000000 ffffffff810874f8 .........t......
ffffffff0113e750: ffffffff011542c8 726f635f656d766e .B......nvme_cor
ffffffff0113e760: 0000000000000065 0000000000000000 e...............
ffffffff0113e770: 0000000000000000 0000000000000000 ................
crash> vtop ffffffff0113e740
VIRTUAL PHYSICAL
ffffffff0113e740 8254d740
PGD: ffffffff810e9ff8 => 2ffff001
P4D: 0000000000000000 => 000000002fffec01
PUD: 00005605c2957470 => 0000000020949801
PMD: 00007fff7f1750c0 => 0000000020947401
PTE: 0 => 209534e7
PAGE: 000000008254d000
PTE PHYSICAL FLAGS
209534e7 8254d000 (PRESENT|READ|WRITE|GLOBAL|ACCESSED|DIRTY)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ff6000003f0777d8 8254d000 0 0 1 0
crash> bt
PID: 113 TASK: ff6000000226c200 CPU: 0 COMMAND: "sh"
#0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8
#1 [ff20000010333cf0] panic at ffffffff806578c6
#2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
#3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
#4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
#5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
#6 [ff20000010333e40] vfs_write at ffffffff80152bb2
#7 [ff20000010333e80] ksys_write at ffffffff80152eda
#8 [ff20000010333ed0] sys_write at ffffffff80152f52
-------
Changes V1 -> V2:
1, Do the below fixes based on HAGIO KAZUHITO's comments:
Fix build warnings,
Use MACRO for Linux version,
Add description of x86_64 binary for riscv64 in README,
Fix build error for the "sticky" target for build on x86_64,
Fix the mixed indent.
2, Add 'help -m/M' support patch to this patch set.
3, Support native compiling approach, which means the host OS distro
is also a riscv64 (lp64d) Linux, based on Yixun Lan's comments.
4, Use __riscv and __riscv_xlen instead of __riscv64__ based on Yixun Lan's comments.
Xianting Tian (9):
Add RISCV64 framework code support
RISCV64: Make crash tool enter command line and support some commands
RISCV64: Add 'dis' command support
RISCV64: Add 'irq' command support
RISCV64: Add 'bt' command support
RISCV64: Add 'help -r' command support
RISCV64: Add 'help -m/M' command support
RISCV64: Add 'mach' command support
RISCV64: Add the implementation of symbol verify
Makefile | 7 +-
README | 4 +-
configure.c | 43 +-
defs.h | 248 +++++++-
diskdump.c | 21 +-
help.c | 2 +-
lkcd_vmdump_v1.h | 2 +
lkcd_vmdump_v2_v3.h | 4 +-
netdump.c | 22 +-
ramdump.c | 2 +
riscv64.c | 1492 +++++++++++++++++++++++++++++++++++++++++++
symbols.c | 10 +
12 files changed, 1847 insertions(+), 10 deletions(-)
create mode 100644 riscv64.c
--
2.17.1
2 years