[PATCH 0/3] Fix several build failures
by Lianbo Jiang
The patchset includes three patches:
[1] [PATCH 1/3] Fix build failure in readline lib
[2] [PATCH 2/3] tools.c: do not use keywords 'nullptr' as a variable in code
[3] [PATCH 3/3] Fix build failure on 32bit machine(i686)
Lianbo Jiang (3):
Fix build failure in readline lib
tools.c: do not use keywords 'nullptr' as a variable in code
Fix build failure on 32bit machine(i686)
gdb-10.2.patch | 88 +++++++++++++++++++++++++++++++++++++++++++++++--
gdb_interface.c | 4 +--
tools.c | 6 ++--
3 files changed, 90 insertions(+), 8 deletions(-)
--
2.47.1
2 months, 3 weeks
Re: [PATCH] x86_64: Fix 'bt -S/-I' segfault issue
by lijiang
Thank you for pointing out this issue, Kazu.
Tao and Kazu, Can I add "Reported-by" from Kazu?
On Fri, Jan 24, 2025 at 10:39 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Fri, 24 Jan 2025 00:11:19 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH] x86_64: Fix 'bt -S/-I' segfault issue
> To: devel(a)lists.crash-utility.osci.io
> Cc: Tao Liu <ltao(a)redhat.com>
> Message-ID: <20250123111119.139008-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> The "pcp" and "spp" can be NULL for "bt -S/-I", but the value is not
> checked before pointer dereference, which lead to segfault error.
> This patch fix this by delay the pointer dereference after
> x86_64_get_dumpfile_stack_frame().
>
>
This looks good to me, so: Ack.
Thanks
Lianbo
> Before:
> crash> bt -S ffffbccee0087ab8
> PID: 2179 TASK: ffffa0f78912a3c0 CPU: 43 COMMAND: "bash"
> Segmentation fault (core dumped)
>
> After:
> crash> bt -S ffffbccee0087ab8
> PID: 2179 TASK: ffffa0f78912a3c0 CPU: 43 COMMAND: "bash"
> #0 [ffffbccee0087b10] __crash_kexec at ffffffffad20c30a
> #1 [ffffbccee0087bd0] panic at ffffffffadcbce30
> #2 [ffffbccee0087c50] sysrq_handle_crash at ffffffffad802b86
> ...
>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> x86_64.c | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/x86_64.c b/x86_64.c
> index c254c6e..d4bbd15 100644
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -5009,16 +5009,11 @@ static void
> x86_64_get_stack_frame(struct bt_info *bt, ulong *pcp, ulong *spp)
> {
> struct user_regs_bitmap_struct *ur_bitmap;
> - ulong pcp_save = *pcp;
> - ulong spp_save = *spp;
> - ulong sp;
> + ulong sp = 0;
>
> if (bt->flags & BT_SKIP_IDLE)
> bt->flags &= ~BT_SKIP_IDLE;
> - if (pcp)
> - *pcp = x86_64_get_pc(bt);
> - if (spp)
> - sp = *spp = x86_64_get_sp(bt);
> +
> ur_bitmap = (struct user_regs_bitmap_struct
> *)GETBUF(sizeof(*ur_bitmap));
> memset(ur_bitmap, 0, sizeof(*ur_bitmap));
>
> @@ -5091,31 +5086,36 @@ x86_64_get_stack_frame(struct bt_info *bt, ulong
> *pcp, ulong *spp)
> if (bt->flags & BT_DUMPFILE_SEARCH) {
> FREEBUF(ur_bitmap);
> bt->need_free = FALSE;
> - *pcp = pcp_save;
> - *spp = spp_save;
> return x86_64_get_dumpfile_stack_frame(bt,
> pcp, spp);
> }
> }
> } else {
> if (!is_task_active(bt->task)) {
> - readmem(*spp, KVADDR, &(ur_bitmap->ur.bp),
> - sizeof(ulong), "ur_bitmap->ur.bp",
> FAULT_ON_ERROR);
> - SET_REG_BITMAP(ur_bitmap->bitmap,
> x86_64_user_regs_struct, bp);
> + if (spp) {
> + *spp = x86_64_get_sp(bt);
> + readmem(*spp, KVADDR, &(ur_bitmap->ur.bp),
> + sizeof(ulong), "ur_bitmap->ur.bp",
> FAULT_ON_ERROR);
> + SET_REG_BITMAP(ur_bitmap->bitmap,
> x86_64_user_regs_struct, bp);
> + }
> } else {
> if (bt->flags & BT_DUMPFILE_SEARCH) {
> FREEBUF(ur_bitmap);
> bt->need_free = FALSE;
> - *pcp = pcp_save;
> - *spp = spp_save;
> return x86_64_get_dumpfile_stack_frame(bt,
> pcp, spp);
> }
> }
> }
>
> - ur_bitmap->ur.ip = *pcp;
> - ur_bitmap->ur.sp = sp;
> - SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, ip);
> - SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, sp);
> + if (pcp) {
> + *pcp = x86_64_get_pc(bt);
> + ur_bitmap->ur.ip = *pcp;
> + SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct,
> ip);
> + }
> + if (spp) {
> + *spp = x86_64_get_sp(bt);
> + ur_bitmap->ur.sp = sp + *spp;
> + SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct,
> sp);
> + }
>
> bt->machdep = ur_bitmap;
> bt->need_free = TRUE;
> --
> 2.47.0
>
3 months
Re: [PATCH v1 2/5] Call cmd_bt silently after "set pid"
by lijiang
Hi, Tao and Alex
Thank you for working on this.
On Fri, Jan 3, 2025 at 1:54 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Fri, 3 Jan 2025 18:48:14 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH v1 2/5] Call cmd_bt silently after
> "set pid"
> To: devel(a)lists.crash-utility.osci.io
> Cc: alexey.makhalov(a)broadcom.com
> Message-ID: <20250103054817.364053-3-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Cmd bt will list multi-stacks of one task. After we "set <pid>" switch
> context to one task, we first need a bt call to detect the multi-stacks,
> however we don't want any console output from it, so a nullfp is used for
> output receive. The silent bt call is only triggered once as part of task
> context switch by cmd set.
>
> A array of user_regs pointers is reserved for each supported arch. If one
> extra stack found, a user_regs structure will be allocated for storing regs
> value of the stack.
>
> Co-developed-by: Alexey Makhalov <alexey.makhalov(a)broadcom.com>
> Co-developed-by: Tao Liu <ltao(a)redhat.com>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> arm64.c | 4 ++++
> crash_target.c | 5 +++++
> gdb-10.2.patch | 2 +-
> kernel.c | 20 ++++++++++++++++++++
> ppc64.c | 4 ++++
> x86_64.c | 3 +++
> 6 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/arm64.c b/arm64.c
> index 1cdde5f..8291301 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -126,6 +126,10 @@ struct user_regs_bitmap_struct {
> ulong bitmap[32];
> };
>
>
I have no more comments about the patchset, only two things:
[1] This was defined in various architectures such as X86 64, aarch64 and
ppc64, can it be defined in a common file and included with define macros
such as "#if defined(X86_64) || defined(ARM64) || defined(PPC64)"?
+#define MAX_EXCEPTION_STACKS 7
> +ulong extra_stacks_idx = 0;
> +struct user_regs_bitmap_struct *extra_stacks_regs[MAX_EXCEPTION_STACKS] =
> {0};
> +
>
And also add code comments to say why it(max exception stacks) is 7.
[2] build warning
cc -c -g -DX86_64 -DLZO -DGDB_10_2 kernel.c -I./gdb-10.2/bfd
-I./gdb-10.2/include -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes
-fstack-protector -Wformat-security
kernel.c:12009:6: warning: no previous prototype for ‘silent_call_bt’
[-Wmissing-prototypes]
12009 | void silent_call_bt(void)
| ^~~~~~~~~~~~~~
static inline bool is_mte_kvaddr(ulong addr)
> {
> /* check for ARM64_MTE enabled */
> diff --git a/crash_target.c b/crash_target.c
> index c5ad1df..8cfa744 100644
> --- a/crash_target.c
> +++ b/crash_target.c
> @@ -31,6 +31,9 @@ extern "C" int crash_get_current_task_reg (int regno,
> const char *regname,
> extern "C" int gdb_change_thread_context (void);
> extern "C" int gdb_add_substack (int);
> extern "C" void crash_get_current_task_info(unsigned long *pid, char
> **comm);
> +#if defined (TARGET_X86_64) || defined (TARGET_ARM64) || defined
> (TARGET_PPC64)
> +extern "C" void silent_call_bt(void);
> +#endif
>
> /* The crash target. */
>
> @@ -164,6 +165,10 @@ gdb_change_thread_context (void)
> /* 3rd, refresh regcache for tid 0 */
> target_fetch_registers(get_current_regcache(), -1);
> reinit_frame_cache();
> +#if defined (TARGET_X86_64) || defined (TARGET_ARM64) || defined
> (TARGET_PPC64)
> + /* 4th, invoke bt silently to refresh the additional stacks */
> + silent_call_bt();
>
This looks tricky, but I have no idea for the time being, maybe we can
improve it in the future.
Other changes are fine to me.
Thanks
Lianbo
+#endif
> return TRUE;
> }
>
> diff --git a/gdb-10.2.patch b/gdb-10.2.patch
> index c867660..7baa925 100644
> --- a/gdb-10.2.patch
> +++ b/gdb-10.2.patch
> @@ -55,7 +55,7 @@ exit 0
> # your system doesn't have fcntl.h in /usr/include (which is where it
> # should be according to Posix).
> -DEFS = @DEFS@
> -+DEFS = -DCRASH_MERGE @DEFS@
> ++DEFS = -DCRASH_MERGE -DTARGET_${CRASH_TARGET} @DEFS@
> GDB_CFLAGS = -I. -I$(srcdir) -I$(srcdir)/config \
> -DLOCALEDIR="\"$(localedir)\"" $(DEFS)
>
> diff --git a/kernel.c b/kernel.c
> index 8c2e0ca..1c8f500 100644
> --- a/kernel.c
> +++ b/kernel.c
> @@ -12001,3 +12001,23 @@ int get_linux_banner_from_vmlinux(char *buf,
> size_t size)
>
> return TRUE;
> }
> +
> +#if defined(X86_64) || defined(ARM64) || defined(PPC64)
> +extern ulong extra_stacks_idx;
> +extern void *extra_stacks_regs[];
> +void silent_call_bt(void)
> +{
> + FILE *fp_save = fp;
> + fp = pc->nullfp;
> +
> + for (int i = 0; i < extra_stacks_idx; i++) {
> + FREEBUF(extra_stacks_regs[i]);
> + extra_stacks_regs[i] = NULL;
> + }
> + sprintf(pc->command_line, "bt\n");
> + argcnt = parse_line(pc->command_line, args);
> + optind = 1;
> + cmd_bt();
> + fp = fp_save;
> +}
> +#endif
> \ No newline at end of file
> diff --git a/ppc64.c b/ppc64.c
> index 7ac12fe..532eb3f 100644
> --- a/ppc64.c
> +++ b/ppc64.c
> @@ -80,6 +80,10 @@ struct user_regs_bitmap_struct {
> ulong bitmap[32];
> };
>
> +#define MAX_EXCEPTION_STACKS 7
> +ulong extra_stacks_idx = 0;
> +struct user_regs_bitmap_struct *extra_stacks_regs[MAX_EXCEPTION_STACKS] =
> {0};
> +
> static int is_opal_context(ulong sp, ulong nip)
> {
> uint64_t opal_start, opal_end;
> diff --git a/x86_64.c b/x86_64.c
> index 53ae3ef..e544be8 100644
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -160,6 +160,9 @@ struct user_regs_bitmap_struct {
> ulong bitmap[32];
> };
>
> +ulong extra_stacks_idx = 0;
> +struct user_regs_bitmap_struct *extra_stacks_regs[MAX_EXCEPTION_STACKS] =
> {0};
> +
> /*
> * Do all necessary machine-specific setup here. This is called several
> * times during initialization.
> --
> 2.47.0
>
3 months
Re: [PATCH] fix build error on target machine 32
by lijiang
Hi, Guanyou
Thank you for the patch.
I fixed several build failures in patchset:
[PATCH 0/3 ] Fix several build failures
Which includes the compilation issue you reported.
Thanks
Lianbo
On Tue, Jan 21, 2025 at 11:43 AM Guanyou Chen <chenguanyou9338(a)gmail.com>
wrote:
> Hi lianbo
>
> make target=arm
>
> frame.c: In function ‘CORE_ADDR frame_unwind_pc (struct frame_info
> *this_frame)’: frame.c:982:29:
> error: cannot convert ‘CORE_ADDR*’ {aka ‘long long unsigned int*’} to
> ‘ulong*’
> {aka ‘long unsigned int*’} 982 | crash_decode_ptrauth_pc(&pc);
>
> See: gdbsupport/common-types.h
> typedef uint64_t CORE_ADDR;
>
> diff --git a/gdb-10.2.patch b/gdb-10.2.patch
> index fd6fadb..a0a8812 100644
> --- a/gdb-10.2.patch
> +++ b/gdb-10.2.patch
> @@ -16223,7 +16223,7 @@ exit 0
> }
>
> +#ifdef CRASH_MERGE
> -+extern "C" void crash_decode_ptrauth_pc(ulong* pc);
> ++extern "C" void crash_decode_ptrauth_pc(uint64_t* pc);
> +#endif
> +
> static CORE_ADDR
> diff --git a/gdb_interface.c b/gdb_interface.c
> index e108d09..2aba81f 100644
> --- a/gdb_interface.c
> +++ b/gdb_interface.c
> @@ -1084,8 +1084,8 @@ int crash_get_current_task_reg (int regno, const
> char *regname,
> }
>
> /* arm64 kernel lr maybe has patuh */
> -void crash_decode_ptrauth_pc(ulong *pc);
> -void crash_decode_ptrauth_pc(ulong *pc)
> +void crash_decode_ptrauth_pc(uint64_t *pc);
> +void crash_decode_ptrauth_pc(uint64_t *pc)
> {
> #ifdef ARM64
> struct machine_specific *ms = machdep->machspec;
>
> Thanks
> Gunayou
>
3 months
[PATCH] x86_64: Fix 'bt -S/-I' segfault issue
by Tao Liu
The "pcp" and "spp" can be NULL for "bt -S/-I", but the value is not
checked before pointer dereference, which lead to segfault error.
This patch fix this by delay the pointer dereference after
x86_64_get_dumpfile_stack_frame().
Before:
crash> bt -S ffffbccee0087ab8
PID: 2179 TASK: ffffa0f78912a3c0 CPU: 43 COMMAND: "bash"
Segmentation fault (core dumped)
After:
crash> bt -S ffffbccee0087ab8
PID: 2179 TASK: ffffa0f78912a3c0 CPU: 43 COMMAND: "bash"
#0 [ffffbccee0087b10] __crash_kexec at ffffffffad20c30a
#1 [ffffbccee0087bd0] panic at ffffffffadcbce30
#2 [ffffbccee0087c50] sysrq_handle_crash at ffffffffad802b86
...
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
x86_64.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/x86_64.c b/x86_64.c
index c254c6e..d4bbd15 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -5009,16 +5009,11 @@ static void
x86_64_get_stack_frame(struct bt_info *bt, ulong *pcp, ulong *spp)
{
struct user_regs_bitmap_struct *ur_bitmap;
- ulong pcp_save = *pcp;
- ulong spp_save = *spp;
- ulong sp;
+ ulong sp = 0;
if (bt->flags & BT_SKIP_IDLE)
bt->flags &= ~BT_SKIP_IDLE;
- if (pcp)
- *pcp = x86_64_get_pc(bt);
- if (spp)
- sp = *spp = x86_64_get_sp(bt);
+
ur_bitmap = (struct user_regs_bitmap_struct *)GETBUF(sizeof(*ur_bitmap));
memset(ur_bitmap, 0, sizeof(*ur_bitmap));
@@ -5091,31 +5086,36 @@ x86_64_get_stack_frame(struct bt_info *bt, ulong *pcp, ulong *spp)
if (bt->flags & BT_DUMPFILE_SEARCH) {
FREEBUF(ur_bitmap);
bt->need_free = FALSE;
- *pcp = pcp_save;
- *spp = spp_save;
return x86_64_get_dumpfile_stack_frame(bt, pcp, spp);
}
}
} else {
if (!is_task_active(bt->task)) {
- readmem(*spp, KVADDR, &(ur_bitmap->ur.bp),
- sizeof(ulong), "ur_bitmap->ur.bp", FAULT_ON_ERROR);
- SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, bp);
+ if (spp) {
+ *spp = x86_64_get_sp(bt);
+ readmem(*spp, KVADDR, &(ur_bitmap->ur.bp),
+ sizeof(ulong), "ur_bitmap->ur.bp", FAULT_ON_ERROR);
+ SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, bp);
+ }
} else {
if (bt->flags & BT_DUMPFILE_SEARCH) {
FREEBUF(ur_bitmap);
bt->need_free = FALSE;
- *pcp = pcp_save;
- *spp = spp_save;
return x86_64_get_dumpfile_stack_frame(bt, pcp, spp);
}
}
}
- ur_bitmap->ur.ip = *pcp;
- ur_bitmap->ur.sp = sp;
- SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, ip);
- SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, sp);
+ if (pcp) {
+ *pcp = x86_64_get_pc(bt);
+ ur_bitmap->ur.ip = *pcp;
+ SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, ip);
+ }
+ if (spp) {
+ *spp = x86_64_get_sp(bt);
+ ur_bitmap->ur.sp = sp + *spp;
+ SET_REG_BITMAP(ur_bitmap->bitmap, x86_64_user_regs_struct, sp);
+ }
bt->machdep = ur_bitmap;
bt->need_free = TRUE;
--
2.47.0
3 months
bug report: "bt -S" option causes a segfault on x86_64
by HAGIO KAZUHITO(萩尾 一仁)
Hi Tao, Lianbo,
Using the latest crash (0f39e33), "bt -S" option always causes a segfault.
crash> bt
PID: 5897 TASK: ffff8ee3cf4e1a00 CPU: 2 COMMAND: "sysrq-panic.sh"
#0 [ffffb39fc107fc00] machine_kexec at ffffffff9b26f107
#1 [ffffb39fc107fc58] __crash_kexec at ffffffff9b3e4b9a
#2 [ffffb39fc107fd18] panic at ffffffff9bda56e6
...
crash> bt -S ffffb39fc107fc00
PID: 5897 TASK: ffff8ee3cf4e1a00 CPU: 2 COMMAND: "sysrq-panic.sh"
Segmentation fault
crash-8.0.5 doesn't cause this with the same command.
crash> bt -S ffffb39fc107fc00
PID: 5897 TASK: ffff8ee3cf4e1a00 CPU: 2 COMMAND: "sysrq-panic.sh"
#0 [ffffb39fc107fc58] __crash_kexec at ffffffff9b3e4b9a
#1 [ffffb39fc107fd18] panic at ffffffff9bda56e6
#2 [ffffb39fc107fd98] sysrq_handle_crash at ffffffff9b93ec16
...
Looking the core and source,
Program terminated with signal 11, Segmentation fault.
#0 x86_64_get_stack_frame (bt=0x7ffe84940e30, pcp=0x7ffe84940600, spp=0x0) at x86_64.c:5013
5013 ulong spp_save = *spp;
(gdb) bt
#0 x86_64_get_stack_frame (bt=0x7ffe84940e30, pcp=0x7ffe84940600, spp=0x0) at x86_64.c:5013
#1 0x000000000057900a in back_trace (bt=bt@entry=0x7ffe84940e30) at kernel.c:3094
#2 0x000000000058472b in cmd_bt () at kernel.c:2781
#3 0x00000000004fe1ac in exec_command () at main.c:893
#4 0x00000000004fe43a in main_loop () at main.c:840
#5 0x0000000000810b4d in captured_main (data=data@entry=0x7ffe84941610) at main.c:1284
#6 gdb_main (args=args@entry=0x7ffe84941630) at main.c:1313
#7 0x0000000000810c05 in gdb_main_entry (argc=<optimized out>, argv=argv@entry=0x7ffe84941798) at main.c:1338
#8 0x000000000058fff9 in gdb_main_loop (argc=<optimized out>, argc@entry=3, argv=argv@entry=0x7ffe84941798) at gdb_interface.c:81
#9 0x00000000004f6c65 in main (argc=3, argv=0x7ffe84941798) at main.c:721
3013 void
3014 back_trace(struct bt_info *bt)
3015 {
...
3091 eip = bt->hp->eip;
3092 esp = bt->hp->esp;
3093
3094 machdep->get_stack_frame(bt, eip ? NULL : &eip,
3095 esp ? NULL : &esp);
5011 static void
5012 x86_64_get_stack_frame(struct bt_info *bt, ulong *pcp, ulong *spp)
5013 {
5014 struct user_regs_bitmap_struct *ur_bitmap;
5015 ulong pcp_save = *pcp;
5016 ulong spp_save = *spp; <<--
5017 ulong sp;
So it may be fixed like "spp_save = spp ? *spp : 0" here (also pcp for bt -I),
but spp/pcp are passed to x86_64_get_dumpfile_stack_flame() too, and it looks
like this function doesn't check whether they are NULL.
*pcp = pcp_save;
*spp = spp_save;
return x86_64_get_dumpfile_stack_frame(bt, pcp, spp);
Do you have any idea about how to fix the issue?
(Is the BT_DUMPFILE_SEARCH block not executed with them being NULL? because
they were not checked also before 89ff1e4573...)
Thanks,
Kazu
3 months
[PATCH] fix build error on target machine 32
by Guanyou Chen
Hi lianbo
make target=arm
frame.c: In function ‘CORE_ADDR frame_unwind_pc (struct frame_info
*this_frame)’: frame.c:982:29:
error: cannot convert ‘CORE_ADDR*’ {aka ‘long long unsigned int*’} to
‘ulong*’
{aka ‘long unsigned int*’} 982 | crash_decode_ptrauth_pc(&pc);
See: gdbsupport/common-types.h
typedef uint64_t CORE_ADDR;
diff --git a/gdb-10.2.patch b/gdb-10.2.patch
index fd6fadb..a0a8812 100644
--- a/gdb-10.2.patch
+++ b/gdb-10.2.patch
@@ -16223,7 +16223,7 @@ exit 0
}
+#ifdef CRASH_MERGE
-+extern "C" void crash_decode_ptrauth_pc(ulong* pc);
++extern "C" void crash_decode_ptrauth_pc(uint64_t* pc);
+#endif
+
static CORE_ADDR
diff --git a/gdb_interface.c b/gdb_interface.c
index e108d09..2aba81f 100644
--- a/gdb_interface.c
+++ b/gdb_interface.c
@@ -1084,8 +1084,8 @@ int crash_get_current_task_reg (int regno, const char
*regname,
}
/* arm64 kernel lr maybe has patuh */
-void crash_decode_ptrauth_pc(ulong *pc);
-void crash_decode_ptrauth_pc(ulong *pc)
+void crash_decode_ptrauth_pc(uint64_t *pc);
+void crash_decode_ptrauth_pc(uint64_t *pc)
{
#ifdef ARM64
struct machine_specific *ms = machdep->machspec;
Thanks
Gunayou
3 months
Re: [PATCH] arm64: add pac mask to better support gdb stack unwind
by lijiang
On Tue, Dec 31, 2024 at 7:22 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Mon, 30 Dec 2024 11:52:32 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] Re: [PATCH] arm64: add pac mask to better
> support gdb stack unwind
> To: Guanyou Chen <chenguanyou9338(a)gmail.com>
> Cc: Lianbo <lijiang(a)redhat.com>, devel(a)lists.crash-utility.osci.io
> Message-ID:
> <
> CAO7dBbVE0rcpZwrfmeBxKmnZfAOFGGCWWNQrX0Jm5SH+yrMZwA(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Guanyou,
>
> Thanks for the fix, the patch looks good to me and tested well. So ack.
>
Applied for v4:
https://github.com/crash-utility/crash/commit/0f39e33d3504f3a17b83574c3be...
Thanks
Lianbo
>
> Thanks,
> Tao Liu
>
3 months, 1 week
Re: [PATCH] Fix misleading CPU count in display_sys_stats()
by lijiang
On Tue, Jan 14, 2025 at 11:52 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Thu, 9 Jan 2025 15:59:20 +1300
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] Re: [PATCH] Fix misleading CPU count in
> display_sys_stats()
> To: soakley(a)redhat.com
> Cc: devel(a)lists.crash-utility.osci.io
> Message-ID:
> <
> CAO7dBbXO5q4ad049R4Qtj14hoi97xy_13-Nja-1VMUwGGgem5A(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Lucas,
>
> Thanks for the fix, LGTM, so ack.
>
Applied(with slight changes):
https://github.com/crash-utility/crash/commit/88453095a3dd54b0950f7d9011f...
Thanks
Lianbo
>
> Thanks,
> Tao Liu
>
>
> On Sat, Jan 4, 2025 at 10:54 AM <soakley(a)redhat.com> wrote:
> >
> > From: Lucas Oakley <soakley(a)redhat.com>
> >
> > This simplication fixes the total CPU count being reported
> > incorrectly in ppc64le and s390x systems when some number of
> > CPUs have been offlined, as the kt->cpus value is adjusted.
> > This adds the word "OFFLINE" to the 'sys' output for s390x
> > and ppc64le, like exists for x86_64 and aarch64 when examining
> > systems with offlined CPUs.
> >
> > Without patch:
> >
> > KERNEL: /debug/4.18.0-477.10.1.el8_8.s390x/vmlinux
> > DUMPFILE: /proc/kcore
> > CPUS: 1
> >
> > With patch:
> >
> > KERNEL: /debug/4.18.0-477.10.1.el8_8.s390x/vmlinux
> > DUMPFILE: /proc/kcore
> > CPUS: 2 [OFFLINE: 1]
> >
> > Signed-off-by: Lucas Oakley <soakley(a)redhat.com>
> > ---
> > kernel.c | 16 +++++++---------
> > 1 file changed, 7 insertions(+), 9 deletions(-)
> >
> > diff --git a/kernel.c b/kernel.c
> > index 8c2e0ca..3e190f1 100644
> > --- a/kernel.c
> > +++ b/kernel.c
> > @@ -5816,15 +5816,13 @@ display_sys_stats(void)
> > pc->kvmdump_mapfile);
> > }
> >
> > - if (machine_type("PPC64"))
> > - fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
> > - else {
> > - fprintf(fp, " CPUS: %d", kt->cpus);
> > - if (kt->cpus - get_cpus_to_display())
> > - fprintf(fp, " [OFFLINE: %d]",
> > - kt->cpus - get_cpus_to_display());
> > - fprintf(fp, "\n");
> > - }
> > + int number_cpus_to_display = get_cpus_to_display();
> > + int number_cpus_present = get_cpus_present();
> > + fprintf(fp, " CPUS: %d", number_cpus_present);
> > + if (number_cpus_present != number_cpus_to_display)
> > + fprintf(fp, " [OFFLINE: %d]",
> > + number_cpus_present - number_cpus_to_display);
> > + fprintf(fp, "\n");
> >
> > if (ACTIVE())
> > get_xtime(&kt->date);
> > --
> > 2.47.1
>
3 months, 1 week
Re: [PATCH] Fix misleading CPU count in display_sys_stats()
by lijiang
Thank you for the fix, Lucas.
On Sat, Jan 4, 2025 at 5:54 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Fri, 3 Jan 2025 16:52:18 -0500
> From: soakley(a)redhat.com
> Subject: [Crash-utility] [PATCH] Fix misleading CPU count in
> display_sys_stats()
> To: devel(a)lists.crash-utility.osci.io
> Cc: Lucas Oakley <soakley(a)redhat.com>
> Message-ID: <20250103215218.712496-1-soakley(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> From: Lucas Oakley <soakley(a)redhat.com>
>
> This simplication fixes the total CPU count being reported
> incorrectly in ppc64le and s390x systems when some number of
> CPUs have been offlined, as the kt->cpus value is adjusted.
> This adds the word "OFFLINE" to the 'sys' output for s390x
> and ppc64le, like exists for x86_64 and aarch64 when examining
> systems with offlined CPUs.
>
> Without patch:
>
> KERNEL: /debug/4.18.0-477.10.1.el8_8.s390x/vmlinux
> DUMPFILE: /proc/kcore
> CPUS: 1
>
> With patch:
>
> KERNEL: /debug/4.18.0-477.10.1.el8_8.s390x/vmlinux
> DUMPFILE: /proc/kcore
> CPUS: 2 [OFFLINE: 1]
>
> Signed-off-by: Lucas Oakley <soakley(a)redhat.com>
> ---
> kernel.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/kernel.c b/kernel.c
> index 8c2e0ca..3e190f1 100644
> --- a/kernel.c
> +++ b/kernel.c
> @@ -5816,15 +5816,13 @@ display_sys_stats(void)
> pc->kvmdump_mapfile);
> }
>
> - if (machine_type("PPC64"))
> - fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
> - else {
> - fprintf(fp, " CPUS: %d", kt->cpus);
> - if (kt->cpus - get_cpus_to_display())
> - fprintf(fp, " [OFFLINE: %d]",
> - kt->cpus - get_cpus_to_display());
> - fprintf(fp, "\n");
> - }
> + int number_cpus_to_display = get_cpus_to_display();
> + int number_cpus_present = get_cpus_present();
> + fprintf(fp, " CPUS: %d", number_cpus_present);
> + if (number_cpus_present != number_cpus_to_display)
> + fprintf(fp, " [OFFLINE: %d]",
> + number_cpus_present - number_cpus_to_display);
> + fprintf(fp, "\n");
>
> if (ACTIVE())
> get_xtime(&kt->date);
>
What do you think about the following changes?
diff --git a/kernel.c b/kernel.c
index 8c2e0ca50482..2f451cc6056b 100644
--- a/kernel.c
+++ b/kernel.c
@@ -5816,15 +5816,16 @@ display_sys_stats(void)
pc->kvmdump_mapfile);
}
- if (machine_type("PPC64"))
- fprintf(fp, " CPUS: %d\n", get_cpus_to_display());
- else {
- fprintf(fp, " CPUS: %d", kt->cpus);
- if (kt->cpus - get_cpus_to_display())
- fprintf(fp, " [OFFLINE: %d]",
- kt->cpus - get_cpus_to_display());
- fprintf(fp, "\n");
- }
+ int number_cpus_to_display = get_cpus_to_display();
+ int number_cpus_present = get_cpus_present();
+ if (!number_cpus_present)
+ number_cpus_present = kt->cpus;
+
+ fprintf(fp, " CPUS: %d", number_cpus_present);
+ if (number_cpus_present > number_cpus_to_display)
+ fprintf(fp, " [OFFLINE: %d]",
+ number_cpus_present - number_cpus_to_display);
+ fprintf(fp, "\n");
if (ACTIVE())
get_xtime(&kt->date);
Thanks
Lianbo
--
> 2.47.1
>
3 months, 1 week