Hi Alexey, On Wed, Nov 13, 2024 at 10:56 AM Alexey Makhalov <alexey.makhalov@xxxxxxxxxxxx> wrote: > > Hi Tao, waiting to see your updated patch. > I made a trial patchset in [1], which added support for x86_64/arm64/ppc64 multi-stack. I made the following improvements: 1. Decrease highest_thread_num to prevent thread id from increasing if we change pid/thread for multiple times. 2. Extract the original patch into arch independent and arch specific parts. 3. Reuse the original user_regs_bitmap_struct struct for storing the multi-stack regs. There are still something need to be improved, e.g.: 1. Can we make stacks_regs from global array into a local/malloced array? 2. The "#define MAX_EXCEPTION_STACKS 7" is not good. 3. I have not fully tested the arch specific parts, there might be cases which gdb_add_substack() missed. ... > > >> Implmentation is machine specific. In x86_64, I use cmd_bt() to add > >> additional gdb threads (gdb_add_substack(stack_id) call). Once added, > >> gdb will may call machdep->get_current_task_reg() with corresonding > >> stack_id (sid: new argument). > >> Note: crash 'bt' command must be called for addition threads to appear. > >> > > I guess this is not very user-friendly, I'm trying to improve that. > > > Agree, I though of adding silent 'bt' invocation on current task > set/switch. But it will slowdown initialization and 'set' command. > > If you have other ideas, I happy to hear it. > Sorry I haven't improved this, I agree a silent "bt" is an approach, other than that, I didn't think of a better approach... Anyway, this is worth to be improved. > > >> > >> crash> gdb info threads > >> Id Target Id Frame > >> * 1 94228 SCTP (stack 0) 0xffffffff998eaadf in __inb (port=100) at ./arch/x86/include/asm/shared/io.h:22 > >> 2 94228 SCTP (stack 1) crypto_aead_encrypt (req=req@entry=0xffff96a348352060) at crypto/aead.c:86 > > > > The stack(0,1) doesn't make sense for users, I prefer to set marks for > > each threads, as the follows: > > > > crash> info threads > > Detaching from process 18613 > > Id Target Id Frame > > * 1 18336 insmod crash_setup_regs (oldregs=<optimized > > out>, newregs=<optimized out>) at ./arch/x86/include/asm/kexec.h:134 > > 2 18336 insmod "eframe" 0xffffffffa008300e in ?? () > > > > So the user will know what kind of stack the thread is... > It would be great! Ditto. > For anyone who is interested, please have a try and I'm happy to receive your comments & suggestions. [1]: https://github.com/liutgnu/crash-dev/commits/multi-stack-v2/ Thanks, Tao Liu > > Thanks, > --Alexey > -- Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/ Contribution Guidelines: https://github.com/crash-utility/crash/wiki
