From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ILIFLUOG2GZ5EiAAWB0awg (envelope-from ) for ; Wed, 04 Sep 2024 12:09:39 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; secure) header.d=adacore.com header.i=@adacore.com header.a=rsa-sha256 header.s=google header.b=HqfHGmRo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B37511E353; Wed, 4 Sep 2024 12:09:39 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EA1401E08F for ; Wed, 4 Sep 2024 12:09:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0E4623861820 for ; Wed, 4 Sep 2024 16:09:38 +0000 (GMT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id C98D6385C6C3 for ; Wed, 4 Sep 2024 16:09:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C98D6385C6C3 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C98D6385C6C3 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::333 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725466143; cv=none; b=T5F41KV2/H+UfNqmS7m9KQ391xhuAxdttA/7l3s71SMJ18aETcb5TrYGWM6wOYz1rhAvKX+WB49KwGP3mzsqFuMKSZsecIbriLOu32VVyK+rn3mAtkBwRIt7IWEuIoMRGjv0MIMRKygjTbmgLKsfdYD4DckiASVf2I0UdHsOuI8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725466143; c=relaxed/simple; bh=5tK41vLp+r2jTAsPzIMjXEpDtgJc29nINYfYCm1IJ6U=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=I/MnRUkFt9MRtqbxiEdzbUPGM+886T4uvD1wnQA4GDASeUwr7b7QlHmRztNzB2aqElxGiXyQDQKTRWpUHz8l0gL9m2x5G5vKn0aD0MnwD82uvZytJ7qE8yR+d0FtEzhv22DtAHYvbp4g2guNjqtg37QO0Sv17AqOyUz+/hXKE9M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-42bb8c6e250so8422475e9.1 for ; Wed, 04 Sep 2024 09:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1725466139; x=1726070939; darn=sourceware.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=w0bzCMAaR01gL9p+8UtX91RwPOTBEmSUfax4Rl4e5NI=; b=HqfHGmRoJspv20q5hS9FYOtJwnyhNSgUlekYKCvHphTn4Irvn9bIuJuQvXwV2D1WXn 1djBtaPhQBcCA1drH0ul6vdlWVIPboNTDP48W/idJo9wX3yKLOayb10oMwcuaZhiKgDn EHEeHJ7s9Rc39F3DI6OcyRCFdJKnV4NYGfv9gh7RLscISRny7PVFg778fSZDpylona8d DLLRkdFa6Cj2Nu4or2QcSGwQ3ZMBd7QLgN0qG52Q3qYSVq40n0BBDUFWxDaqTiejTf6O bLRg2p6ZV/g2KJDugsVJM9hk1kM/kuugEv8koWF7BBzbb0m2qhCPCobv9m7WerkL7WjM lSSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725466139; x=1726070939; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=w0bzCMAaR01gL9p+8UtX91RwPOTBEmSUfax4Rl4e5NI=; b=WXnBnrv19SBalPPf9DTi4giluFPBZzr/9LeOiT4dZOukRgojQqLWDH40SWe6oKHERX phGZXixUxUKNHZTsSWybmR6glRRLlvsrh6Xh1BtWF0lAk4mI6XXLxW1uty3XVbPKDc30 SCNST50dUdFYbAf1HUJNZOn7oORqpgcnPUuI5HskSZ+30ghEwn5U57OHnGC1EsuIrT0y qh01LXWvw/e9V45fiYrlonMpNNbF5KbIQ8fVVPT17LPCG3uTDHwbY0XtdLVYmvFHxPQe g4/Ilz3ymuIeEfT3+E0zK44eVGtSTkpkFOAtiX01vTkxFpuETgbmJQicZmg3+6qVkw9G S+IA== X-Gm-Message-State: AOJu0YxDAh+rz0o4eESFdiF7P7uv7hKgbiw6z8du0yZ5kH57zHsAkeOm JlwesAxp8fJFZhzMyfuSW6H5ofMBFruV4iwFdE7DTCJGWV0V70YATujWtaC2aLljaNvv1vS+mSQ = X-Google-Smtp-Source: AGHT+IGla9R/R3LrDHzY9aN1cQKHDzVRFd9UuqHEnh2RNH270zNEXJRppYGYikGB1ffnFmLhul4Qfg== X-Received: by 2002:a05:600c:450e:b0:426:623f:34ae with SMTP id 5b1f17b1804b1-42c9545cd88mr24304015e9.16.1725466138765; Wed, 04 Sep 2024 09:08:58 -0700 (PDT) Received: from legouguec-Precision-7550 ([2.57.72.67]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bb6e33d55sm211996085e9.41.2024.09.04.09.08.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 09:08:58 -0700 (PDT) From: =?utf-8?Q?K=C3=A9vin_Le_Gouguec?= To: Andrew Burgess Cc: gdb-patches@sourceware.org, Thiago Jung Bauermann Subject: Re: [PATCH v2] Refrain from asking debug stubs to read invalid memory In-Reply-To: <87jzfru4rc.fsf@redhat.com> (Andrew Burgess's message of "Wed, 04 Sep 2024 10:50:31 +0100") References: <20240318161955.668163-1-legouguec@adacore.com> <20240903130045.2957421-1-legouguec@adacore.com> <87jzfru4rc.fsf@redhat.com> Date: Wed, 04 Sep 2024 18:08:57 +0200 Message-ID: <87a5gnz9ie.fsf@adacore.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Andrew Burgess writes: > But *sigh* I see we already have code that's special casing 0 in this > function, so maybe adding yet more is just something I'll need to > accept. >=20 FWIW, it's not clear-cut to me that this needs to go in, as-is or otherwise. See below. > Or in your case (qemu) then the emulator should just be fixed > to return an error on these accesses. (Clarification: the remote stub under test was not QEMU's, but the one implemented by RTEMS's libdebugger, linked against the application, _running inside the QEMU guest_. So, reason #1 for not going with this approach: it is not clear to me how widespread this problem is; we only observed it for that one target; could not find the time to test a newer libdebugger, let alone take the plunge and try to fix the stub) > Anyway, I do have a more substantial question, I guess when you talk > about the resolve_dynamic_type calls in ::read_var_value, you are > talking about the lines like this: >=20 > type =3D resolve_dynamic_type (type, view, /* Unused address. */ 0); >=20 > The problem you see is that these end up calling: >=20 > read_memory_typed_address (addr_stack->addr, type); >=20 > in resolve_dynamic_type_internal. Now as far as I can tell this > function will throw an exception if the read fails. Right; to expand on the commit message, the symptoms were that (a) while usually 'target remote' would greet us with=E2=80=A6 (gdb) target remote localhost:7100 Remote debugging using localhost:7100 _User_extensions_Thread_switch (executing=3D0x0, heir=3D) =E2=80=A6 it would instead tell us=E2=80=A6 (gdb) target remote localhost:7100 Remote debugging using localhost:7100 _User_extensions_Thread_switch (executing=3D0x0,=20 Ignoring packet error, continuing... heir=3D) =E2=80=A6 and (b) subsequent commands would timeout. (Fingers crossed I am not getting details wrong; going with what I put on record in our internal tracker 6 months ago. Which brings me to reason #2 for dropping this: for internal reasons, testing new changes on this target configuration is no longer a priority; finding time to research a better fix and/or a test case will thus prove challenging) > So, surely, if > we're sending through '0' as an address with the expectation that we'll > not access the address ... but now we are ... then surely this would > trigger an exception on a target where 0 is not readable, but the target > doesn't hang, right? For example, x86-64 GNU/Linux. >=20 > Which makes me think: can't we write a test case for this bug? A test case would be ideal, but not sure how to produce one. The test harness for that target config is a handful (adapting that internal test framework into DejaGNU "boards" is on my pipe-dream list); for other targets (e.g. x86-64 GNU/Linux) I have not managed to tickle GDB into producing a similar error. tl;dr Unless we can produce a test case, maybe we should drop this patch? If we eventually hit this failure mode internally for target configs that are easier to capture into a test case, I would pick it back up and investigate, but until then it is not obvious to me this needs to go in. Lest I forget: thank you very much for the feedback; I was indeed wondering about "targets out there that can read from address 0" when working on this, but lacked ideas to do much about it.