On 3/26/21 7:46 PM, Stefan Metzmacher wrote: > > Hi Jens, > >> root@ub1704-166:~# LANG=C gdb --pid 1320 >> GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2 >> Copyright (C) 2020 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. >> Type "show copying" and "show warranty" for details. >> This GDB was configured as "x86_64-linux-gnu". >> Type "show configuration" for configuration details. >> For bug reporting instructions, please see: >> <http://www.gnu.org/software/gdb/bugs/>. >> Find the GDB manual and other documentation resources online at: >> <http://www.gnu.org/software/gdb/documentation/>. >> >> For help, type "help". >> Type "apropos word" to search for commands related to "word". >> Attaching to process 1320 >> [New LWP 1321] >> [New LWP 1322] >> >> warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386 >> >> warning: Architecture rejected target-supplied description >> syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 >> 38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory. >> (gdb) > > Ok, the following makes gdb happy again: > > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -163,6 +163,8 @@ int copy_thread(unsigned long clone_flags, unsigned long sp, unsigned long arg, > /* Kernel thread ? */ > if (unlikely(p->flags & (PF_KTHREAD | PF_IO_WORKER))) { > memset(childregs, 0, sizeof(struct pt_regs)); > + if (p->flags & PF_IO_WORKER) > + childregs->cs = current_pt_regs()->cs; > kthread_frame_init(frame, sp, arg); > return 0; > } Confirmed, it stops complaining about the arch at that point. > I'm wondering if we should decouple the PF_KTHREAD and PF_IO_WORKER > cases even more and keep as much of a userspace-like copy_thread as > possible. Probably makes sense, the only thing they really share is the func+arg setup. Hence PF_IO_WORKER threads likely just use the rest of the init, where it doesn't conflict with the frame setup. -- Jens Axboe
