From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41138 invoked by alias); 10 Jul 2018 01:14:35 -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 41127 invoked by uid 89); 10 Jul 2018 01:14:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=tuesday, Consolidate, skeptical, Tuesday X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Jul 2018 01:14:33 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5FEC94001388 for ; Tue, 10 Jul 2018 01:14:32 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2F7A2111C481; Tue, 10 Jul 2018 01:14:32 +0000 (UTC) From: Sergio Durigan Junior To: Stan Cox Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [RFC][PATCH v3] Consolidate gdbserver global variables References: <3153f899-a653-9372-72fd-25ea874f7d3c@redhat.com> <44875dda-adc6-d9a4-940c-0c27aeac574b@redhat.com> <6a41763b-6949-2d32-37fa-9d3f1afceec1@redhat.com> <7d9764b6-d95a-96b4-b064-27ce539327cf@redhat.com> <9988957e-3bf8-cbe8-6c08-58706b11bd60@redhat.com> <9e844707-a2f8-c969-4d09-7ee2fa3bd1ed@redhat.com> Date: Tue, 10 Jul 2018 01:14:00 -0000 In-Reply-To: <9e844707-a2f8-c969-4d09-7ee2fa3bd1ed@redhat.com> (Stan Cox's message of "Tue, 8 May 2018 16:58:34 -0400") Message-ID: <87wou3x56w.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00235.txt.bz2 On Tuesday, May 08 2018, Stan Cox wrote: > (Addressed formatting and ChangeLog issues) > >> As mentioned, I'm skeptical of all client_state references >> in the backends. >> >> How will this work with multiple clients? What if one client >> wants exec events, and the other one doesn't? This seems to >> suggest that the backends need to enable exec events if _any_ >> client wants them (or unconditionally), and then filter out exec >> events at a higher level, before reporting the event to >> each client? > > Perhaps filtering that is roughly analogous to the way > gdb_catch_this_syscall_p filters for particular syscalls. > >> This "= 0" is a spurious change. Remove it. > > Removed (it eliminated a compiler warning with gcc 7.3.1) > >> Give the global different name to avoid conflict with >> the type name. Maybe "g_client_state" or "the_client_state". > > Used g_client_state and also made it static instead of allocating it > with new. > >> What's the plan for last_status/last_ptid? >> Shouldn't those be per-client too? > > Added those. > >> Should these two be per client? I'd think so off hand, >> since they correspond to the Hc/Hg threads? > > Added cont_thread and general_thread > >> I suspect that it'd be better to make the server_waiting >> global be per-process instead > > Returned to server_waiting being a global for now. > > > Thanks Pedro! > > > Tested on linux with native-gdbserver. Hi Stan, This patch introduced a regression on GDB when testing with --target_board=native-gdbserver. The failure is described here: https://sourceware.org/bugzilla/show_bug.cgi?id=23378 I've been trying to narrow down the cause, but so far have not been very successful. It seems that everything was covered by your patch, so I'm guessing there must be some hidden spot where we're forgetting to update some internal state and the failure ends up happening. For the sake of comparison, here's the output that should have been printed: Expecting: ^(-var-update L[ ]+)?(\^done,changelist=\[{name="L",in_scope="true",type_changed="false",has_more="0"}\][ ]+[(]gdb[)] [ ]*) -var-update L ^done,changelist=[{name="L",in_scope="true",type_changed="false",has_more="0"}] (gdb) PASS: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now And this is what the failure looks like: Expecting: ^(-var-update L[ ]+)?(\^done,changelist=\[{name="L",in_scope="true",type_changed="false",has_more="0"}\][ ]+[(]gdb[)] [ ]*) -var-update L ^done,changelist=[] (gdb) FAIL: gdb.mi/mi-var-cmd.exp: in-and-out-of-scope: in scope now (unexpected output) Something to take into consideration is that gdbserver is restarted many times during the testcase. I think this may have something to do with it, because the test doesn't fail on native-extended-gdbserver. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/