Re: improved thread id reporting

[Doug Evans <dje at google dot com>]

On Sat, Apr 4, 2009 at 6:11 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sat, Apr 04, 2009 at 03:17:02PM -0700, Doug Evans wrote:
>> > That said, if it's possible to print them without creating additional
>> > line breaks on an 80-column wide screen, I have no objections.
>> >
>> >> To fix (1) I'd like to simply remove the pthread id from the output.
>> >
>> > I think that's a bad idea.
>>
>> Even as a user-settable option?
>
> IMO, yes. ?I don't think we need more settable options for details of
> output formatting; 98% or so of users will use the default, so that's
> the part that matters.

Oh well, 2 out of 3 ...
[Modulo one could provide a command to look up the pthread id given
the thread number, or provide an option to "info threads" to include
or not include it.  I'm just mentioning that for completeness sake
though.]

Question: Why does remote.c print pid.tid? [ref: remote_pid_to_str]
[I know I said it's kinda nice, but I still have a question.]

IOW, if printing pid is good for remote.c then why isn't it good for non-remote?
And if it's not good for non-remote, then why is it good for remote?
[I'm specifically referring to the linux case, but I'm guessing the
same applies to any gdbserver situation where one _could_ debug
locally as well.]
In the linux case at least the difference doesn't seem warranted
(except as some compromise, but why compromise?).

windows-nat.c:windows_pid_to_str, for example, prints pid.hex-tid.  In
the windows case is pid the same for every thread? (in the
non-multiprocess case)  Is there a case (windows or otherwise) where
pid _could_ be different for different threads in the non-multiprocess
case?  I'd expect not (gdb pretty much assumes ptid.pid is the same
for all threads in a process, right?), but please let me know if I'm
wrong.

So if one were to start over, it seems like the printing of the pid
for every thread is better left to something else ("info proc pid" or
some such?  If "proc" has too much of a linux connotation (/proc,
et.al.) then maybe "info inferior pid"?  And if something like that
makes sense, can we remove the printing of pid from multi-threaded
target_pid_to_str's and remote_pid_to_str?

It seems like the pretty-printing of a ptid_t is not a property of the
target, per se (to the extent that all else being equal there doesn't
seem to be a justification for printing local linux ptids different
from remote linux ptids - I gather there was an implementation problem
in communicating remote pthread_t's over the remote protocol, but I'm
guessing what's there now is a compromise and not the preferred
choice).
I can't think of an existing place to move target_pid_to_str though.  Blech.
And there's nothing else on the target stack for remote_pid_to_str to
defer to; IWBN if we could somehow teach it to print what the local
version would print.