I'm not holding my breath, but: On Wed, May 5, 2021 at 2:59 PM Simon Marchi <simon.marchi@xxxxxxxxxx> wrote: > > On 2021-05-05 7:29 a.m., Stefan Metzmacher wrote: > > See https://lore.kernel.org/io-uring/0375b37f-2e1e-7999-53b8-c567422aa181@xxxxxxxxx/ > > and https://lore.kernel.org/io-uring/20210411152705.2448053-1-metze@xxxxxxxxx/T/#m461f280e8c3d32a49bc7da7bb5e214e90d97cf65 > > > > The question is why does inferior_ptid doesn't represent the thread > > that was specified by 'gdb --pid PIDVAL' > > Hi Stefan, > > When you attach to PIDVAL (assuming that PIDVAL is a thread-group > leader), GDB attaches to all the threads of that thread group. The > inferior_ptid global variable is "the thread we are currently working > with", and changes whenever GDB wants to deal with a different thread. > > After attaching to all threads, GDB wants to know more about that > process' architecture (that read_description call mentioned in [1]). ^^^^^^ For what it's worth, this is already fundamentally incorrect. On x86_64 Linux, a process *does* *not* *have* an architecture. Every task on an x86_64 Linux host has a full 64-bit register state. The task can, and sometimes does, change CS using far transfers or other bizarre techniques, and neither the kernel nor GDB will be notified or have a chance to take any action in response. ELF files can be 32-bit, CS:rIP can point at 32-bit code, and system calls can be 32-bit (even from 64-bit code), but *tasks* are not 32-bit. Now I realize that the ptrace() API is awful and makes life difficult in several respects for no good reason but, if gdb is ever interested in fixing its ideas about architecture to understand that all tasks, even those that think of themselves as "compat", have full 64-bit state, I would be more than willing to improve the ptrace() API as needed to make this work well. Since I'm not holding my breath, please at least keep in mind that anything you do here is merely a heuristic, cannot be fully correct, and then whenever gdb determines that a thread group or a thread is "32-bit", gdb is actually deciding to operate in a degraded mode for that task, is not accurately representing the task state, and is at risk of crashing, malfunctioning, or crashing the inferior due to its incorrect assumptions. If you have ever attached gdb to QEMU's gdbserver and tried to debug the early boot process of a 64-bit Linux kernel, you may have encountered this class of bugs. gdb works very, very poorly for this use case. (To avoid confusion, this is not a universal property of Linux. arm64 and arm32 tasks on an arm64 Linux host are different and cannot arbitrarily switch modes.) --Andy
