What to do with threads?

What to do with threads?

[Andrew Cagney]

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.

Andrew

Re: What to do with threads?

[Quality Quorum]

On Sun, 2 Feb 2003, Andrew Cagney 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.

Again, the battle would much easier if we will refactor to C++ ASAP.

>
> Andrew
>

Thanks,

Aleksey

Re: What to do with threads?

[Andrew Cagney]

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

Re: What to do with threads?

[Daniel Jacobowitz]

On Mon, Mar 03, 2003 at 06:40:08PM -0500, Andrew Cagney wrote:
> 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 ...

Definitely sounds like a change whose time has come.  There's one
hiccup in that when we go from one-process to one-thread we need to
update the thread ID; you can see how I handled this (inelegantly) in
gdbserver.  Gdbserver's always got a thread... more or less.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: What to do with threads?

[Andrew Cagney]

> On Mon, Mar 03, 2003 at 06:40:08PM -0500, Andrew Cagney wrote:
> 
>> 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 ...
> 
> 
> Definitely sounds like a change whose time has come.  There's one
> hiccup in that when we go from one-process to one-thread we need to
> update the thread ID; you can see how I handled this (inelegantly) in
> gdbserver.  Gdbserver's always got a thread... more or less.

Hmm, true.  A target changed event should flush that problem, such an 
operation has not just a faint wiff but rather the very unhealty stench 
of a `radically changed target'.

Andrew