From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65033 invoked by alias); 3 Oct 2017 11:06:37 -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 65020 invoked by uid 89); 3 Oct 2017 11:06:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2354, H*r:sk:clients, HX-Received:10.223.166.196, H*r:sk:static. X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Oct 2017 11:06:34 +0000 Received: by mail-wr0-f176.google.com with SMTP id 54so6017488wrz.10 for ; Tue, 03 Oct 2017 04:06:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=2DQjHugBriHXybS6jYk3KtckJwJUsGg8e1LNn6fN32I=; b=L1/k1z4E7PRLwZ1c/McyTJkhjN58ajPatHxVZDzaUcUzQWeSTsgT0caT4rQRWJaBSX fu15ZDoBNUY3JAPqikklapVyXPAXelSjFRoW/WzHtrpvZBvcRR+SUshZZYf+gEYPdRr6 FlyIbADfiZx4hA4KfK/L60EAm6NDIKLL1dSmFvjMaco+TseYpr72obe04HX4KRNHTz6W C4R4+Q3blpCysAupPUcrSCRKElhgajF5QOy73N+MnZAfXhrDH6Jy3WWFB7RdfiXmiBAo PGs2Jx6vq5ZE2XcuSjP/KTdoIAlc8ksIEQlvXWypcfW8qGxWqWMPngVGoN2CZWJOf4zl m9sg== X-Gm-Message-State: AHPjjUhYUcRlrKSMC9RXj8EcbX6tu5Xi0+OQYiFPsQEUawUvKDo6XCPe WVQaBlxmCyrmzX7jMPyti/nqHg== X-Google-Smtp-Source: AOwi7QBN9NaAcE4Vr9YhfyFKGsBs2IHe7EIi1IrIwXDLF27nmHS2CnX8tUmI7+Wt2w/l6ViLJIA8Ow== X-Received: by 10.223.166.196 with SMTP id t62mr16930052wrc.251.1507028792554; Tue, 03 Oct 2017 04:06:32 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id z10sm28268234wre.6.2017.10.03.04.06.31 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 03 Oct 2017 04:06:32 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] Redesign mock environment for gdbarch selftests References: <1506957311-30028-1-git-send-email-palves@redhat.com> <1506957311-30028-2-git-send-email-palves@redhat.com> Date: Tue, 03 Oct 2017 11:06:00 -0000 In-Reply-To: <1506957311-30028-2-git-send-email-palves@redhat.com> (Pedro Alves's message of "Mon, 2 Oct 2017 16:15:09 +0100") Message-ID: <86k20c7aob.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00031.txt.bz2 Pedro Alves writes: > If there's already a running target when you type "maint selftest", > then we bail out, instead of pushing a new target on top of the > existing one (and thus killing the debug session). I think that's OK, > because self tests are really mean to be run from a clean state right > after GDB is started. I'm adding that skipping just as safe measure > just in case someone (as I've done it) types "maint selftest" on the > command line while already debugging something. That is a goo catch, but IMO, we shouldn't allow running unit tests during debugging session. GDB unit tests touch many things, and some of them are global states in GDB. It is difficult to know what global states we need to restore after tests. > > (In my multi-target branch, where this patch originated from, we don't > actually need to bail out, because there each inferior has its own > target stack). > > Also, note that the current code was doing: > > current_inferior()->gdbarch =3D gdbarch; > > without taking care to restore the previous gdbarch. This means that > GDB's state was being left inconsistent after running the self tests,, > further supporting the point that there's probably not much > expectation that mixing "maint selftests" and regular debugging in the > same GDB invocation really works. You are right, we should manage the expectation of mixing debugging and "maint selftests". My suggestion is that "please do run selftests with regular debugging". > - raw_set_cached_value (regnum, buf); > + to_magic =3D OPS_MAGIC; > + to_stratum =3D process_stratum; > + to_has_memory =3D test_target_has_memory; > + to_has_stack =3D test_target_has_stack; > + to_has_registers =3D test_target_has_registers; > + to_prepare_to_store =3D test_target_prepare_to_store; > + to_fetch_registers =3D test_target_fetch_registers; to_fetch_registers is TARGET_DEFAULT_IGNORE, so we don't need define test_target_fetch_registers if we disallow running selftests with regular debugging. > + to_store_registers =3D test_target_store_registers; > + to_thread_architecture =3D default_thread_architecture; > + to_thread_address_space =3D default_thread_address_space; Any reason to set to_thread_address_space and to_thread_architecture? Can't we use the default value? --=20 Yao (=E9=BD=90=E5=B0=A7)