From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18793 invoked by alias); 4 Mar 2003 14:35:40 -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 18781 invoked from network); 4 Mar 2003 14:35:40 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 4 Mar 2003 14:35:40 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A7BD82A9C; Tue, 4 Mar 2003 09:35:38 -0500 (EST) Message-ID: <3E64B9BA.90009@redhat.com> Date: Tue, 04 Mar 2003 14:35: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: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: What to do with threads? References: <3E3D87B5.9080306@redhat.com> <3E63E7D8.2030401@redhat.com> <20030304025913.GA31172@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00079.txt.bz2 > 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