From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82470 invoked by alias); 1 Jul 2016 14:58:18 -0000 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 Received: (qmail 82360 invoked by uid 89); 1 Jul 2016 14:58:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=surface, paper X-HELO: bigwig.baldwin.cx Received: from bigwig.baldwin.cx (HELO bigwig.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 01 Jul 2016 14:58:11 +0000 Received: from John-Baldwins-MacBook-Pro.local (d-69-161-105-82.cpe.metrocast.net [69.161.105.82]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 451C0B96E; Fri, 1 Jul 2016 10:58:09 -0400 (EDT) Subject: Re: [PATCH 0/2] Fix x86 debug registers on FreeBSD with threads To: Pedro Alves , gdb-patches@sourceware.org References: <20160628225507.80772-1-jhb@FreeBSD.org> <5d3788cc-400b-3efa-4a88-dc3a072ce706@redhat.com> From: John Baldwin Message-ID: <0397773c-07ea-acfa-b14d-5252ce09fef6@FreeBSD.org> Date: Fri, 01 Jul 2016 14:58:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5d3788cc-400b-3efa-4a88-dc3a072ce706@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00011.txt.bz2 On 7/1/16 9:02 AM, Pedro Alves wrote: > On 06/28/2016 11:55 PM, John Baldwin wrote: >> The pan-BSD x86 debug register support code was only setting the >> debug registers on the current LWP identified by inferior_ptid. >> This fixes the code to set the debug registers on all of the LWPs >> belonging to the current inferior on each change. > > Looks good to me. > > Spotted a missing space in: > > ALL_NON_EXITED_THREADS(thread) Fixed in pushed version, thanks. >> One question I have is that the amd64 x86 debug register code was >> invoking x86_cleanup_dregs in the mourn_inferior target op, but >> the x86 linux native code calls this in the post_startup_inferior >> target op instead. Any ideas as to why they are different? > > Not sure. Probably history, or maybe to be sure to paper over > potential problems from the "inferior exit/dies/detached" end missing > clearing the reg state. OTOH, I think target_post_startup_inferior > isn't called for attach. > Note that mourn_inferior isn't called in some cases. Some targets call > it from within their to_detach and to_kill target methods, but that's > not guaranteed. I think that linux-nat.c doesn't call it from its > to_detach, but OTOH, when you get there, watchpoints had better have > been removed from the target already. But maybe there's a problem > as follow-fork time, not sure. Note that the linux native code > also calls x86_forget_process directly through linux_nat_forget_process. Hmm, it seems that for FreeBSD at least mourn_inferior is only called from inf_ptrace_kill() and not from detach either. I'll have to think about this more. On the surface it would seem that mourn_inferior could at least use x86_forget_process to only discard state for the process going away rather than discarding the entire list. -- John Baldwin