Re: What to do with threads?

Andrew Cagney
2003-03-03T23:40:10Z

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