From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16654 invoked by alias); 21 Mar 2017 14:27:45 -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 16642 invoked by uid 89); 21 Mar 2017 14:27:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy= X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Mar 2017 14:27:43 +0000 Received: by mail-wm0-f49.google.com with SMTP id t189so13800477wmt.1 for ; Tue, 21 Mar 2017 07:27:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7oZTN5ziQuDHQrV5jrj8no7RiLW7O1C0S0D/YbLIwKI=; b=gqRpmRFfb46pUciAzpOYN3oNU5v6/tH6pQGJQZ9JpIX6oBacAX5GjmuHSKH+CwEnQp TY3akyHGNPvyVCSUkYkbSC5A48HU09/zwYGkofkN0la7SlFL5fmBvcq75HiIdJgiwaUf iwD79YO6SHcglhgX9/QbyrLxpmmX/GIHbR/qTb5icZPU+leLK1nC29QGjp6r52HOudYF 4BeRtVW+CmvpflUnBd8YyH2LOnlAr1uv/psPAHBhtAVBCHXQ6nS+Ox4CRa5WKlshPZBt Vs8lstkwaBveVfxFt4AhjwdBdn3kQ60mrxOw/7vqREbyN5zxHYml7JaA49UqFIGRjdHk ElkA== X-Gm-Message-State: AFeK/H0gkxQ8V2VVD7AmJKR2RGVltzJ0bIhNqW14TgMgSzp6gB3829t0z+Dtxr0Ax0oT40rl X-Received: by 10.28.63.66 with SMTP id m63mr2934199wma.82.1490106462730; Tue, 21 Mar 2017 07:27:42 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id m7sm5870737wmi.34.2017.03.21.07.27.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 07:27:42 -0700 (PDT) Subject: Re: [PATCH 3/3] windows: Use ptid from regcache in register fetch/store To: Simon Marchi References: <20170318170801.22988-1-simon.marchi@polymtl.ca> <20170318170801.22988-3-simon.marchi@polymtl.ca> <41e56d7a-3bf6-71d5-6f5e-03c721ee4ff9@redhat.com> <80d736666fe9a1484f57f8c60a1f64df@polymtl.ca> Cc: gdb-patches@sourceware.org, Simon Marchi From: Pedro Alves Message-ID: <419e195c-66dd-3d05-d945-2dc0646e6a44@redhat.com> Date: Tue, 21 Mar 2017 14:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <80d736666fe9a1484f57f8c60a1f64df@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00373.txt.bz2 On 03/20/2017 10:22 PM, Simon Marchi wrote: >>> static void >>> -do_windows_fetch_inferior_registers (struct regcache *regcache, int r) >>> +do_windows_fetch_inferior_registers (struct regcache *regcache, >>> + windows_thread_info *th, int r) >>> { >>> char *context_offset = ((char *) ¤t_thread->context) + >>> mappings[r]; >> >> Is this reference to "current_thread" still correct? > > Oops, I guess it should be th, like the rest: > > char *context_offset = ((char *) th->context) + mappings[r]; > > Fixed locally. Thanks. > >>> @@ -537,25 +533,26 @@ static void >>> windows_fetch_inferior_registers (struct target_ops *ops, >>> struct regcache *regcache, int r) >>> { >>> - current_thread = thread_rec (ptid_get_tid (inferior_ptid), TRUE); >>> + DWORD pid = ptid_get_tid (regcache_get_ptid (regcache)); >>> + windows_thread_info *th = thread_rec (pid, TRUE); >>> + >>> /* Check if current_thread exists. Windows sometimes uses a >>> non-existent >>> thread id in its events. */ >> >> The comment is out of date now. > > Fixed locally. > >> Did you look for the history around these comments? I wonder whether >> these NULL checks still make sense here if we always reference the >> regcache's thread. The equivalent code in gdbserver doesn't seem to >> have them. > > All I know is that this is the patch that introduced them: > https://sourceware.org/ml/gdb-patches/2003-12/msg00479.html > > The PR 1048 seems to refer to a pre-bugzilla bug tracking system. Do we > still have them somewhere? Here: https://sourceware.org/gdb/wiki/DeveloperTips?highlight=%28gnats%29#Finding_Gnats_bug_entries_in_the_Bugzilla_database gnats 1048 + 7105 -> bugzilla 8153: https://sourceware.org/bugzilla/show_bug.cgi?id=8153 > > From what I understand, it's the use case where you attach to a process > whose main thread has already exited. If the patch introduced these > NULL checks, I suppose it's because they were necessary back then to > work around the Windows bug. I have no idea if they are still > necessary, or if the Microsoft people fixed it. [...] > In any case, the fact > of whether the checks are needed is not impacted by the current patch: > in the end, we call thread_rec with the same pid with which we would > have called it before, so we should get the same result. You're right. > > I'll wait for your input on this before sending a new version. > I don't have further input. Thanks, Pedro Alves