[FYI/pushed v4 08/25] Thread options & clone events (Linux GDBserver)
Luis Machado
luis.machado@arm.com
Wed Feb 7 18:05:12 GMT 2024
Replying to both Tom's and Simon's comments.
On 2/7/24 17:10, Simon Marchi wrote:
> On 2/7/24 10:43, Tom Tromey wrote:
>>>>>>> "Luis" == Luis Machado <luis.machado@arm.com> writes:
>>
>> Luis> But find_process_pid returns nullptr. I wonder if it is one of those cases
>> Luis> where we have to deal with the tid rather than the pid.
>>
>> Luis> Does this look like the same case you were chasing?
>>
>> Yes. The issue is that the new inferior isn't created until after the
>> new thread -- but the order can't really be reversed in the caller.
>>
I see. Is this logic expected? Naturally I'd expect a process to exist before a thread can exist.
I haven't followed the patch series closely though, so there may be a reason for it.
>> I've appended the patch. I put off sending it because for internal
>> reasons it hasn't been through the AdaCore automated testing yet.
>> However, I did test it (using the AdaCore test suite -- not gdb's)
>> myself.
>>
>> Let me know what you think.
It does fix the regressions I was seeing, but Simon made some good points as well.
>>
>> Tom
>>
>> commit 5464152cb1145bc1df108eb6904a642d8bc73b8c
>> Author: Tom Tromey <tromey@adacore.com>
>> Date: Mon Feb 5 13:18:51 2024 -0700
>>
>> Fix crash in aarch64-linux gdbserver
>>
>> We noticed that aarch64-linux gdbserver will crash when the inferior
>> vforks. This happens in aarch64_get_debug_reg_state:
>>
>> struct process_info *proc = find_process_pid (pid);
>>
>> return &proc->priv->arch_private->debug_reg_state;
>>
>> Here, find_process_pid returns nullptr -- the new inferior hasn't yet
>> been created in linux_process_target::handle_extended_wait.
>>
>> This patch fixes the problem by having aarch64_get_debug_reg_state
>> return nullptr in this case, and then updating
>> aarch64_linux_new_thread to check for this.
>>
>> diff --git a/gdb/nat/aarch64-linux.c b/gdb/nat/aarch64-linux.c
>> index 5ebbc9b81f8..894de8aa3eb 100644
>> --- a/gdb/nat/aarch64-linux.c
>> +++ b/gdb/nat/aarch64-linux.c
>> @@ -81,9 +81,9 @@ aarch64_linux_new_thread (struct lwp_info *lwp)
>> /* If there are hardware breakpoints/watchpoints in the process then mark that
>> all the hardware breakpoint/watchpoint register pairs for this thread need
>> to be initialized (with data from aarch_process_info.debug_reg_state). */
>> - if (aarch64_any_set_debug_regs_state (state, false))
>> + if (state == nullptr || aarch64_any_set_debug_regs_state (state, false))
>> DR_MARK_ALL_CHANGED (info->dr_changed_bp, aarch64_num_bp_regs);
>> - if (aarch64_any_set_debug_regs_state (state, true))
>> + if (state == nullptr || aarch64_any_set_debug_regs_state (state, true))
>> DR_MARK_ALL_CHANGED (info->dr_changed_wp, aarch64_num_wp_regs);
>
> I don't really understand all of this, but I'm wondering if the
> condition should be:
>
> if (state != nullptr && aarch64_any_set_debug_regs_state (state, ...))
>
> If we have no existing aarch64_debug_reg_state, do we really need to
> mark the breakpoints as needing to be updated?
>
I think as long as we have a thread, we should always have the state for the debug registers,
so changing the approach to always initialize the state if there isn't one seems reasonable.
See below.
>> lwp_set_arch_private_info (lwp, info);
>> diff --git a/gdbserver/linux-aarch64-low.cc b/gdbserver/linux-aarch64-low.cc
>> index 28d75d035dc..2a4f01a54da 100644
>> --- a/gdbserver/linux-aarch64-low.cc
>> +++ b/gdbserver/linux-aarch64-low.cc
>> @@ -403,7 +403,8 @@ struct aarch64_debug_reg_state *
>> aarch64_get_debug_reg_state (pid_t pid)
>> {
>> struct process_info *proc = find_process_pid (pid);
>> -
>> + if (proc == nullptr)
>> + return nullptr;
>> return &proc->priv->arch_private->debug_reg_state;
>> }
>
> I was wondering if the GDB version of this function needed to get
> updated too. It works differently:
>
> /* See aarch64-nat.h. */
>
> struct aarch64_debug_reg_state *
> aarch64_get_debug_reg_state (pid_t pid)
> {
> return &aarch64_debug_process_state[pid];
> }
>
> Here, aarch64_debug_process_state is an unordered_map<pid_t,
> aarch64_debug_reg_state>, meaning that if pid isn't currently in the
> map, a default aarch64_debug_reg_state will be constructed (is it going
> to be initialized properly?).
>
> So we end up with two different semantics for the two versions of the
> function, which might become a source of confusion later.
And it would sync the behavior from gdb nat and gdbserver nat layers.
I can put together a patch to do that. I wasn't aware there was this discrepancy
between gdb and gdbserver.
>
> Simon
More information about the Gdb-patches
mailing list