From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4703 invoked by alias); 15 Aug 2008 23:28:07 -0000 Received: (qmail 12106 invoked by uid 22791); 15 Aug 2008 22:54:57 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Aug 2008 22:54:08 +0000 Received: (qmail 28232 invoked from network); 15 Aug 2008 22:54:06 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Aug 2008 22:54:06 -0000 From: Pedro Alves To: "Ulrich Weigand" Subject: Re: [rfc] Preferred thread event reporting: Linux native target Date: Fri, 15 Aug 2008 23:28:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200808142150.m7ELoMaw023976@d12av02.megacenter.de.ibm.com> In-Reply-To: <200808142150.m7ELoMaw023976@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808152354.32763.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00436.txt.bz2 On Thursday 14 August 2008 22:50:22, Ulrich Weigand wrote: > Pedro Alves wrote: > > > -- this is actually simply the currently selected thread > > > (i.e. the current value of inferior_ptid). > > > > Disagreed. inferior_ptid will change if an event happens in > > another thread while you're stepping, but the core decides the event > > was not a good reason to stop. E.g., thread hopping. > > Hmm, but if we "thread hop" inferior_ptid should be prefered > anyway (to get the internal "thread hop" action over with as > quickly as possible), When we thread hop, we tell the target to only allow a single thread to run. On linux, there's no way to could already have a cached event in the thread the user is stepping at this point, otherwise, we'd not have detected the need for a thread hop. So, right after resuming to do the thread hop, if there's any other cached event to select from, because they were cached when we reported the stop that originated the thread hop, it won't be from the thread the user was stepping. But, this above is moot currently, because when we thread hop, we enter infwait_thread_hop_state, which ends up forcing linux_nat_wait to only return with the ptid of the thread we're hopping, thus, the thread hop action gets over as quickly as possible already. > and afterwards we're back to the thread > the user is looking at, right? Well, in all-stop, there's nothing doing that currently. when you switch inferior_ptid (in all-stop mode) to handle a possible stop, and then you decide you should not stop, there's nothing reverting back to the previous thread. inferior_ptid will stay pointing to the last thread you resumed (the hopping thread), until you hit another stop event, and context_switch to the thread that took it. > > For my series to go in, every target much register at least the main > > thread in GDB's thread tables, and as it happens, I think AIX > > is the only target I don't have covered, or that I know of > > no one covering. > > I can test AIX if necessary. Do you have a patch? I stratched my head quite a bit staring at aix-thread.c/sync_threadlists and its use of ptid_cmp. I still can't tell if/what I should do there. Also, I can't tell if rs6000_wait can ever return a ptid different from pid_to_ptid(main_process_pid), (or -1). Basically, I need to: 1) make sure the core never gets a thread related event that corresponds to a thread the core doesn't know about yet. 2) #1 implies that every target should register the main thread, even when debugging a single-threaded app. rs6000-nat.c, being a ptrace based target, already has that covered by these: http://sourceware.org/ml/gdb-patches/2008-08/msg00170.html http://sourceware.org/ml/gdb-patches/2008-08/msg00171.html 3) #2 implies that a thread_stratum layer should decorate the main thread's ptid with thread id info, instead of adding it again. That's thread_change_ptid from: http://sourceware.org/ml/gdb-patches/2008-08/msg00170.html -- Pedro Alves