From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22361 invoked by alias); 3 Mar 2003 23:40:10 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22354 invoked from network); 3 Mar 2003 23:40:10 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 3 Mar 2003 23:40:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8FF752A9C; Mon, 3 Mar 2003 18:40:08 -0500 (EST) Message-ID: <3E63E7D8.2030401@redhat.com> Date: Mon, 03 Mar 2003 23:40:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney , Kevin Buettner Cc: gdb@sources.redhat.com Subject: Re: What to do with threads? References: <3E3D87B5.9080306@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00066.txt.bz2 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