Re: [RFA] improved thread id reporting

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 19 May 2009 00:23:15, Doug Evans wrote:
> Ping.
> 
> Ok to check in?

I haven't convinced myself yet that your normal_stop change always
does what you want.  Won't it print:

[Switching from thread #0 to thread #3, 0x41001960 (LWP 14407)]
                        ^

if the previosly selected thread happens to exit in a series
of misfortunate events?  Say, 

thread 1
break foo thread 2
continue
<thread 3 hits breakpoint at foo, gdb thread hops, having switched inferior_ptid to thread 3>
<thread 1 exits, exit_lwp calls delete_thread>
<thread 2 hits breakpoint at foo, call normal_stop, but previous_inferior_ptid is not in the thread list anymore>

> 
> 
> On Thu, May 7, 2009 at 10:46 PM, Doug Evans <dje@google.com> wrote:
> > Blech.  Right list this time.
> >
> >
> > On Sun, Apr 5, 2009 at 8:33 PM, Daniel Jacobowitz <drow@false.org> wrote:
> >> On Sun, Apr 05, 2009 at 01:36:06PM -0700, Doug Evans wrote:
> >>> Attached is a simplistic patch to help illustrate the challenge.
> >>>
> >>> Here is an example session that prints from/to and the thread number
> >>> in "[New ...", "[Switching ...", etc. messages.
> >>> I can think of two issues with the patch:
> >>> 1) Printing "[tT]hread" twice in one line is a bit annoying.
> >>> 2) Spreading from/to over two lines is a bit annoying.
> >>
> >> What do you think of this?  On the theory that you can go look up
> >> thread #2, either in 'info threads' or in a previous notification:
> >>
> >> [Switching from thread #2 to thread #3, Thread 0x41001960 (LWP 14407)]
> >
> > "works for me"
> >
> >> Or, migrating the "Thread" out:
> >>
> >> [Switching from thread #2 to thread #3, 0x41001960 (LWP 14407)]
> >>
> >> But that might be tricky with multi-process, some ptid_t's are not
> >> threads.
> >
> > It's not clear how multi-process is going to work yet (or more likely
> > I've forgotten).  I played with attaching and running several
> > processes via gdbserver and all processes appear in "info threads".
> > [sidebar: I wouldn't mind "info threads" just showing the threads of
> > the current process, otherwise it might get confusing.  And given that
> > "info inferiors" is used to show all the processes IWBN if "inferior
> > N" switched to the specified process; a straightforward and intuitive
> > mapping from "info threads" + "thread N".]
> >
> > How about this?
> >
> 



-- 
Pedro Alves