Re: [FYI/pushed v4 08/25] Thread options & clone events (Linux GDBserver)

[Luis Machado <luis.machado@arm.com>]

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