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

[Simon Marchi]

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'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.
> 
> 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?

>    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.

Simon