Re: What to do with threads?

[Andrew Cagney <ac131313 at redhat dot com>]

Kevin, to change threads on you (er, sorry, groan)

I wrote:

> Hello,
>
> To put it simply, how can one fix this:
>
> static CORE_ADDR
> d10v_read_pc (ptid_t ptid)
> {
>   ....
>   read_register (PC_REGNUM);
>   ....
> }
>
> There are problems at many levels.  Off the top of my head:
>
> - ptid can identify a thread and/or a LWP
> - there sometimes isn't even a thread and/or a LWP
> - the selected and current thread both fight over the same global data structures
> - long long term, an objective is to have gdb debug multiple processes /  ISAs
> - so long term that it is probably funny, an objective is to have gdb debugging multiple targets
>
> I think we've fought the frame battle and won (the casualties will take ages to recover mind :-), the thread battle, I think, is next.

We wrote:

> On Mar 2,  3:25pm, Andrew Cagney wrote:
>
>
> > Following on from my recent post to add an unwind_dummy_id() method, 
> > this code adds architecture specific methods to handle the edge case of 
> > unwinding the sentinel frame's PC/ID.
> >
> > While I'm pretty sure that the methods are needed, I'm not 100% certain 
> > of their interfaces.  The attached has:
> >
> > 	unwind_sentinel_id(arch, regcache, unwind_cache)
> >
> > I'm wondering if, instead it should use something like:
> >
> > 	unwind_sentinel_id(arch, tpid, unwind_cache)
> >
> > where a new method:
> >
> > 	tpid_regcache (tpid)
> >
> > could be used to obtain the tpid's register cache.  I'm thinking this 
> > since, for the case of the i386, it may need the thread's state in 
> > addition to registers when determing the `pc'.
>
>
> s/tpid/ptid/ in the above.
>
> ptid_regcache() does sound useful.

(I get the feeling that this frame code is currently running head-long 
into the limitiations of the thread code)

Since GDB's frames have a very short life time (flushed the moment there 
is even the faintest wiff of a changed target) it may be possible to 
instead use `struct thread_info':

	struct thread_info *get_frame_thread (frame)

and

	get_thread_regcache (thread_info);

For this to work, though, there would need to be a function that was 
guarenteed to always return a thread_info object.  Such a 
get_selected_thread() or find_thread_by_tpid(?inferior_tpid?) would need 
to return a thread object when there were no threads ...

Andrew