Re: What to do with threads?

[Andrew Cagney <ac131313@redhat.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