[PATCH 07/11] gdb: maintain per-process-target list of resumed threads with pending wait status

[Simon Marchi]

>> Arggg, we don't want that.  Since that is in a process_stratum_target
>> method, I'll change the message to call the pid_to_str method of the
>> current object instead:
>>
>>       infrun_debug_printf ("removing from resumed threads with event list: %s",
>> 			   this->pid_to_str (thread->ptid).c_str ());
>>
>> Does that sound good?
> 
> It does not.  That would mean a target higher on the stack wouldn't have a chance
> at printing the thread.

Since this is only for debug message purposes, and I find it clearer to
see the spelled-out ptid anyway (the pid, lwp and tid values), I added a
to_string method to ptid_t and used that here:

    std::string
    ptid_t::to_string () const
    {
      return string_printf ("%d.%d.%d", m_pid, m_lwp, m_tid);
    }

>>>> +  /* If we transition from not resumed to resumed, we might need to add
>>>> +     the thread to the resumed threads with pending statuses list.  */
>>>> +  if (resumed)
>>>> +    proc_target->maybe_add_resumed_with_pending_wait_status (this);
>>>
>>> Longest function name award goes to...  ;-)
>>
>> Indeed!  If you have a name that is shorter but just as clear, I'm open
>> for suggestion.  But I prefer names that are non-ambiguous and use the
>> right terminology over names that are short just for convenience's sake.
> 
> Sure, as a preference, though that shouldn't be a too-strict rule IMO, otherwise
> with very long function names we can end up with awkward looking code as soon as we
> need to indent a caller a couple levels.  In this case, luckily that didn't happen,
> so I'm not really objecting.
> 
> "add_resumed_pending_status" or "add_resumed_pending_ws" would work as well for
> me, for example.

Ah you see, when I haven't touched some GDB code for a while, I would
see "ws" and wonder what that is again... is GDB using websockets now ;)
?

Simon