[v2] gdb: print thread names in thread apply command output

  This makes the thread apply command print the thread's name.  The use
of target_pid_to_str is replaced by thread_target_id_str, which
provides the same output as "info threads".

Before:
(gdb) thread apply 2 bt

Thread 2 (Thread 0x7fd245602700 (LWP 3837)):
[...]

After:
(gdb) thread apply 2 bt

Thread 2 (Thread 0x7fd245602700 (LWP 3837) "HT cleanup"):
[...]

The thread's description header is pre-computed before running the
command since the command may change the selected inferior. This is
not permitted by thread_target_id_str as target_thread_name asserts
that `info->inf == current_inferior ()`.

This situation arises in the `gdb.threads/threadapply.exp` test which
kills and removes the inferior as part of a "thread apply" command.

gdb/ChangeLog:

        * thread.c (thr_try_catch_cmd): Print thread name.
---
 gdb/ChangeLog |  4 ++++
 gdb/thread.c  | 16 ++++++++++------
 2 files changed, 14 insertions(+), 6 deletions(-)
  

>>>>> "Jérémie" == Jérémie Galarneau <jeremie.galarneau@efficios.com> writes:

Jérémie> This situation arises in the `gdb.threads/threadapply.exp` test which
Jérémie> kills and removes the inferior as part of a "thread apply" command.

Thank you for the patch.

Jérémie> +  /* The thread header is computed before running the command since
Jérémie> +     the command can change the inferior, which is not permitted
Jérémie> +     by thread_target_id_str.  */
Jérémie> +  std::string thr_header =
Jérémie> +    string_printf(_("\nThread %s (%s):\n"), print_thread_id (thr),
Jérémie> +		  thread_target_id_str (thr).c_str ());

Missing a space before the "(" after string_printf here.

IIUC this is fixing a latent bug, is that correct?

Anyway this looks ok to me with that nit fixed.

Tom
  

On Tue, 18 Feb 2020 at 15:57, Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "Jérémie" == Jérémie Galarneau <jeremie.galarneau@efficios.com> writes:
>
> Jérémie> This situation arises in the `gdb.threads/threadapply.exp` test which
> Jérémie> kills and removes the inferior as part of a "thread apply" command.
>
> Thank you for the patch.
>
> Jérémie> +  /* The thread header is computed before running the command since
> Jérémie> +     the command can change the inferior, which is not permitted
> Jérémie> +     by thread_target_id_str.  */
> Jérémie> +  std::string thr_header =
> Jérémie> +    string_printf(_("\nThread %s (%s):\n"), print_thread_id (thr),
> Jérémie> +                thread_target_id_str (thr).c_str ());
>
> Missing a space before the "(" after string_printf here.
>
> IIUC this is fixing a latent bug, is that correct?

Hi Tom,

This is not a bug fix. AFAIK, this information has never been provided
as part of that command's output.

Thanks for the comments!
Jérémie

>
> Anyway this looks ok to me with that nit fixed.
>
> Tom
  

On 2020-02-18 11:24 p.m., Jérémie Galarneau wrote:
>> IIUC this is fixing a latent bug, is that correct?
> 
> Hi Tom,
> 
> This is not a bug fix. AFAIK, this information has never been provided
> as part of that command's output.

I think that Tom is talking about the fact that you moved computing the thread
header before calling the command.  Despite not causing an assertion, it was
technically not correct.  Prior to this patch, we compute the thread label using:

  std::string
  target_pid_to_str (ptid_t ptid)
  {
    return current_top_target ()->pid_to_str (ptid);
  }

Where current_top_target is implemented as:

  target_ops *
  current_top_target ()
  {
    return current_inferior ()->top_target ();
  }

So as you can see, calling target_pid_to_str implicitly relies on the current
inferior (for historical and multi-target reasons that would be too long to
explain this late) to obtain the target to ask to format the ptid.

If the executed command switches the current inferior, it could switch to an
inferior of a different target.  So we would format the ptid of a thread of
target A using the pid_to_str method of target B.

Changing the code to using thread_target_id_str caused us to call
target_thread_name, which luckily has this assertion:

  gdb_assert (info->inf == current_inferior ());

I suppose this assertion should not be necessary normally, as we should be
able to call the thread_name method using a target inferred from the thread:

  info->inf->top_target ()->thread_name (info)

... and not care about the current inferior/target.  However, I presume the
assertion was put there as part of the multi-target work because some
implementations of the thread_name target method might implicitly rely in the
current inferior being set.  So until we audit all these implementations, it
has to stay true.

Simon
  

On 2020-02-18 11:24 p.m., Jérémie Galarneau wrote:
> On Tue, 18 Feb 2020 at 15:57, Tom Tromey <tom@tromey.com> wrote:
>>
>>>>>>> "Jérémie" == Jérémie Galarneau <jeremie.galarneau@efficios.com> writes:
>>
>> Jérémie> This situation arises in the `gdb.threads/threadapply.exp` test which
>> Jérémie> kills and removes the inferior as part of a "thread apply" command.
>>
>> Thank you for the patch.
>>
>> Jérémie> +  /* The thread header is computed before running the command since
>> Jérémie> +     the command can change the inferior, which is not permitted
>> Jérémie> +     by thread_target_id_str.  */
>> Jérémie> +  std::string thr_header =
>> Jérémie> +    string_printf(_("\nThread %s (%s):\n"), print_thread_id (thr),
>> Jérémie> +                thread_target_id_str (thr).c_str ());
>>
>> Missing a space before the "(" after string_printf here.
>>
>> IIUC this is fixing a latent bug, is that correct?
> 
> Hi Tom,
> 
> This is not a bug fix. AFAIK, this information has never been provided
> as part of that command's output.
> 
> Thanks for the comments!
> Jérémie
> 
>>
>> Anyway this looks ok to me with that nit fixed.
>>
>> Tom

FYI, I pushed it with that fixed.

Simon