Re: [RFA] improved thread id reporting

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 19 May 2009 04:29:38, Pedro Alves wrote:
> 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, 

Following a fork is also a case where the previously thread
may be long gone from the thread list when you get here.  Note that
I contructed the contrived case below, because delete_thread
refuses to delete inferior_ptid from the thread list.  There are
several options here: make a better effort at storing the previous
thread id; printing something about previous thread having exited;
or (ugly?) documenting this #0 thing.  I do have my reservations
about being always possible to print a sensible previous thread id.

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