[Crash-utility] Re: [PATCH] gdb bt: multiple stacks support (x86_64)
Hi Alexey,
On Wed, Nov 13, 2024 at 10:56 AM Alexey Makhalov
<alexey.makhalov(a)broadcom.com> wrote:
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
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.