Hi Alexey, On Thu, May 1, 2025 at 7:32 PM Alexey Makhalov <alexey.makha...@broadcom.com> wrote: > > Hi Tao, thanks for the update. > > Do you guys discuss it through some channels other than Crash-utility > mailing list?
Yes, through an internal slack channel, because I and Lianbo are in the same company... > > I tested your patches v2 on top of crash-9.0. It is directly applicable > and no issues or concerns at runtime. And silent bt seems working. LGTM. Wow, that's good news, thanks a lot for your testing! Anyway, I need to run it against a bunch of regression tests, which is the one I run every time before the new version of crash release. In addition, I'm currently working on some other tasks, I will back and handle this patchset in a short while. Sorry again for the delay of the patchset. Thanks, Tao Liu > > Regards, > --Alexey > > On 4/30/25 9:22 PM, Tao Liu wrote: > > Hi Alexey, > > > > The patchset needs to be rebased after upgrading the gdb into version > > v16.2. If we put the "multi-stack unwinding" together with gdb > > upgrading, there will be too much modification for one release. So we > > decided to defer the "multi-stack unwinding" after gdb upgrading. I > > think I will rebase and re-post the "multi-stack" patches later. > > > > Thanks, > > Tao Liu > > > > On Thu, May 1, 2025 at 9:25 AM Alexey Makhalov > > <alexey.makha...@broadcom.com> wrote: > >> > >> Hello Tao and folks! > >> > >> What is the status of this patchset? I expected to see it in 9.0. > >> > >> Thanks, > >> --Alexey > >> > >> > >> On 2/20/25 1:44 PM, Tao Liu wrote: > >>> 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(-) > >>> > >> -- > >> Crash-utility mailing list -- devel@lists.crash-utility.osci.io > >> To unsubscribe send an email to devel-le...@lists.crash-utility.osci.io > >> https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ > >> Contribution Guidelines: https://github.com/crash-utility/crash/wiki > > > -- Crash-utility mailing list -- devel@lists.crash-utility.osci.io To unsubscribe send an email to devel-le...@lists.crash-utility.osci.io https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
