From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id 6929C3858D3C for ; Tue, 19 Apr 2022 22:47:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6929C3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f50.google.com with SMTP id l62-20020a1c2541000000b0038e4570af2fso84840wml.5 for ; Tue, 19 Apr 2022 15:47:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ydXwd2u87qcR9ocJfiPLWhqlYwmc0fstPu7VaOervGw=; b=bylBrlJXfhGCBvfOYGGGllg/z+HxcvgHZcfRH2y2oNEyTpmDZl/fYMIHw26mLXiG42 cj73800a9wXRKW1Q+ouI7gvw1ieQQngG3h2/R9pn9Yxc7AJm1ogen8v1YdIradiWuKc3 Tf22r4t51aRkXwSUyl6drffZ2PYf+P3j9bN45YEcMfNqaQ3mL3/Ws0RDEmwfQx+8jF6Q HI+8SbeRK0Sjh2hGXauIfDwQkPGWT1MyyMQc8uubIYMxKc7YD3JR+aVrg5Wedzgt9GiM MSo/T4/t9QZEuQZknvJaxieJHbZopm3lXxZB6UhLvXoC/OV7WRzZKGks8OBlPxe7ZPrd YQEg== X-Gm-Message-State: AOAM5310g0Ul60arz6AD6k79gJMmITwinNGL635Q20YC8pDZzFO93p6B UuJjYtErdYZj9yQ7MmKQldhzGBw12Hs= X-Google-Smtp-Source: ABdhPJy9nISF55x1a7VpTA0FLnMdQa8SmEtSsDERPWAXIeOsf20jX3iAqn4nI4LfydcVxAgabtuTiQ== X-Received: by 2002:a05:600c:1c9b:b0:391:6287:b7a3 with SMTP id k27-20020a05600c1c9b00b003916287b7a3mr704576wms.188.1650408463389; Tue, 19 Apr 2022 15:47:43 -0700 (PDT) Received: from localhost ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id r9-20020a05600c320900b0038f0894d80csm16488732wmp.7.2022.04.19.15.47.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Apr 2022 15:47:42 -0700 (PDT) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 1/2] Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver Date: Tue, 19 Apr 2022 23:47:38 +0100 Message-Id: <20220419224739.3029868-2-pedro@palves.net> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20220419224739.3029868-1-pedro@palves.net> References: <20220419224739.3029868-1-pedro@palves.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2022 22:47:47 -0000 When testing gdb.threads/access-mem-running-thread-exit.exp with --target_board=native-extended-gdbserver, we get: Running gdb.threads/access-mem-running-thread-exit.exp ... FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main WARNING: Timed out waiting for EOF in server after monitor exit === gdb Summary === # of expected passes 3 # of unexpected failures 1 # of unsupported tests 1 The problem is that the testcase spawns a second inferior with -no-connection, and then runto_main does "run", which fails like so: (gdb) run Don't know how to run. Try "help target". (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main That "run" above failed because native-extended-gdbserver forces "set auto-connect-native-target off", to prevent testcases from mistakenly running programs with the native target, which would exactly be the case here. Fix this by letting the second inferior share the first inferior's connection everywhere except on targets that do reload on run (e.g., --target_board=native-gdbserver). Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed --- .../access-mem-running-thread-exit.exp | 30 ++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp index dddb35dabc0..8dc9af05c8e 100644 --- a/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp +++ b/gdb/testsuite/gdb.threads/access-mem-running-thread-exit.exp @@ -79,7 +79,35 @@ proc test { non_stop } { # Start the second inferior. with_test_prefix "second inferior" { - gdb_test "add-inferior -no-connection" "New inferior 2.*" + # With stub targets that do reload on run, if we let the new + # inferior share inferior 1's connection, runto_main would + # fail because GDB is already connected to something, like + # e.g. with --target_board=native-gdbserver: + # + # (gdb) kill + # ... + # (gdb) target remote localhost:2348 + # Already connected to a remote target. Disconnect? (y or n) + # + # Instead, start the inferior with no connection, and let + # gdb_load/runto_main spawn a new remote connection/gdbserver. + # + # OTOH, with extended-remote, we must let the new inferior + # reuse the current connection, so that runto_main below can + # issue the "run" command, and have the inferior run on the + # remote target. If we forced no connection, then "run" would + # either fail if "set auto-connect-native-target" is on, like + # the native-extended-gdbserver board enforces, or it would + # run the inferior on the native target, which isn't what is + # being tested. + # + # Since it's reload_on_run targets that need special care, we + # default to reusing the connection on most targets. + if [target_info exists gdb,do_reload_on_run] { + gdb_test "add-inferior -no-connection" "New inferior 2.*" + } else { + gdb_test "add-inferior" "New inferior 2.*" + } gdb_test "inferior 2" "Switching to inferior 2 .*" gdb_load $binfile -- 2.26.2