This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: info thread
- From: Alain Magloire <alain at qnx dot com>
- To: Denis PILAT <denis dot pilat at st dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, nickrob at snap dot net dot nz, gdb at sourceware dot org
- Date: Thu, 28 Sep 2006 10:35:22 -0400
- Subject: RE: info thread
> From: Denis PILAT [mailto:denis.pilat@st.com]
> Sent: Wednesday, September 27, 2006 10:18 AM
> To: Alain Magloire
> Cc: Daniel Jacobowitz; nickrob@snap.net.nz; gdb@sourceware.org
> Subject: Re: info thread
>
>
>
> Alain Magloire wrote:
>
> >
> >>I think you're thinking of -thread-list-ids. Ah, this is mi/674.
> >>It's also mi/1040. Both of which suggest *stopped :-)
> >>
> >>We could add the thread to -thread-list-ids, too.
> >>
> >>Something to keep in mind: the thread "extra info" is expensive to
> >>collect on some platforms, e.g. requires asking the remote stub for
> >>details on each individual thread.
> >>
> >>
> >
> >Noted, but some platforms put some extra stuff in the output of "info
> >threads" like thread names, states, mutexes etc ... this information is
> then
> >retrieve by the IDE and shownn to the user.
> >
> Yes but to display this "extra stuffs" they have to customize their
> Eclipse (or any UI) to implement a parser for that.
>
> I think it will be more generic and cost less (in term of execution
> time) if "extra information" could be accessible thru an other mi
> command than -thread-list-ids.
> Generic part of the UI then calls -thread-list-ids
> Targets that want to display more information then just call a more
> complete command like -thread-list-all-threads
> or -thread-info on each thread.
>
>
Agreed, if we the UI views are smart enough to tell which threads are
visible to the users then the implementation can be lazy in getting the
info.
> What I propose is the following:
>
> -thread-list-ids :
> INPUT: none
> OUTPUT:
> o list of IDs
> o Current thread could be the first (or last) item of the list, or
> warned by an asterisk
>
> -thread-list-all-threads
> INPUT: none
> OUTPUT:
> o like -thread-list-ids
> o plus the list of "extra information" per thread
>
>
> -thread-info
> INPUT: thread ID as an optional parameter, if not given the following
> concerns current thread
> OUTPUT:
> o thread ID (could be used to determine which is the current
> thread if not given in parameter)
> o extra information
> o stack frame
>
>
OK. And in term of format, are we talking tuple/list? There was some
inconsistencies in the old MI versions. Also for extra information you are
probably mean "optional extra information" will that be an opaque string or
name=value pairs.
>
> Apart from the debate let me give you some measurements I did on a
> 100 threads program that runs on a board, debugged thru jtag.
> Figures for the "info thread" CLI command only:
> 70 % of the time is spent in getting the stack frame for all threads
> 1% on the "extra info"
> 29% on other stuff out of the loop that collect thread above information.
>
> Stack frame is the one that takes the most since it requires to switch
> the current thread and print the stack. Switching takes 60% of that
> time. Moreover extra information are reduced for our target.
>
> Please note that the total time is 7.2 seconds for this example !
On some architecture "info threads" can make things extremely slow, since
the IDE will have to poll at every step to discover created/destroyed
threads. For the long run we should probably look at notifications.