From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ccIJDsEI12blyB4AWB0awg (envelope-from ) for ; Tue, 03 Sep 2024 09:01:53 -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=DtNjWDeU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id F21FA1E353; Tue, 3 Sep 2024 09:01:52 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-11.8 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,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 4A8901E08F for ; Tue, 3 Sep 2024 09:01:52 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B7B26386182C for ; Tue, 3 Sep 2024 13:01:51 +0000 (GMT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 7D75C385EC38 for ; Tue, 3 Sep 2024 13:01:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D75C385EC38 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 7D75C385EC38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::32b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725368492; cv=none; b=cDoWgjgD1J1q+DOpwQ5E0qMw6xGV2WNv4DW7m6X9y+rkuE0Emdc1ST5I00zfvwEREF+rB3fX2XiUGiH66SwmwBsRu5eidU0rFG2xevoQ6OQR/jC3vxgTruTuBbaxH7TrgX92hBmjf1LwogoBsJravMeFBUYwD9jbP/Ap2jeF8fc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725368492; c=relaxed/simple; bh=uJqmobvgGGQX0D+tvM8rDPdhxEXbd2ajvvSxEFtfiD4=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=v9UGJn4dzn5O4uqO7zLFLGM0gzI9h4TG0cuaFafpUogepNFqY4+j6Q7JCT0PXtJPGscQl0BqeTqTIjfWYbKxoQz/wT+M2ZNKG98Aag0NHP/o/FHn9+jpmrIxnQxSfyPoKf7ZVJaCsHsuYC/w501h9YRoIpEFyijyGf5gg8svHeU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-42ba9b47f4eso30763565e9.1 for ; Tue, 03 Sep 2024 06:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1725368486; x=1725973286; darn=sourceware.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1YrIjQh9rD20gybFBWWtkST8IewVwJr3YmztFBsClAw=; b=DtNjWDeU18S+GKyqe/V0TMlelMKFxF9PZU4mL6jz4GNjuMX8FqwjbiyKZ1jVKU+gir ldkph9QMfckRbGNSqy+XdBIalFtYrprkmT86EK7L30rS8esG8g9x7xJKLZ04+We7eglF jAAoqFSNPZygpUaomlcmerJfjklrC7liUys0+pPEYOVXKv9jbfN83oR3ZlqA57ooRPQW S5nnDLnf+o0GNKe1d7jvLYRBgxBWqji3fbhoWm1H1wOf4c6O9BfZ2GPrYPUMwwIimGCB IbtGHC5kudhU8hUVzmNkbr2hZ9XmWBR+b1q3Oz21PL+tZnHgqnxpKdIKesKNyvH5OQn+ JI0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725368486; x=1725973286; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1YrIjQh9rD20gybFBWWtkST8IewVwJr3YmztFBsClAw=; b=FmfP9oh84h9VVkWpfReQfOIDFwG7nk1cYokMSycyka89Kh804+o6LFSwp0+O2SIlrf SdVWuF7wPU1UUxoGXAVzbRAhNK3JW6+VmKK6oUniRgo3auNvVs1+YbK3cJIsVMdf4SSo a35vnk2kZKV2+DJtQPpcD2ZAXqpIfS+fqtSwbO6RaWFWqxvnDWXoBof/9Qq8ktmj3Eh4 f4+fzllGtzCdgZVvOrRhcgEDa3FtnKIoEGIMHuwDf05X9TwruWeH+69cetwkRoMrz8x6 t84pFVh5+QH9hD/EBw/ogsQO+fdvMUcSSTpvjT8hNA7PZB6ogbMuSsoE+vnOSUQPMYYd aDdg== X-Gm-Message-State: AOJu0YxhPWxmfZr9u0ytSepxP/ukdjDU7Eao+bW+fxslbKwQ/70cxi2a OyVsjT/REH4o5XWiF1w051vPefrn5R8ZbaKP52ZRRFzlnWO+FgiOE+wBsCkybAO3ZWNBGqIaADI = X-Google-Smtp-Source: AGHT+IFzkqZDJqIrHQmQ6kDqoaFDRA2v5UMAD3KxY18aQmJoG1GCYtayKQbuNBJUk5EsjwDpmtFK9Q== X-Received: by 2002:a05:600c:3590:b0:428:f0fc:4e54 with SMTP id 5b1f17b1804b1-42bb4ca9f7amr116808675e9.11.1725368484666; Tue, 03 Sep 2024 06:01:24 -0700 (PDT) Received: from localhost.localdomain ([2.57.72.67]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-374c6479514sm7167577f8f.93.2024.09.03.06.01.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2024 06:01:24 -0700 (PDT) From: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= To: gdb-patches@sourceware.org Cc: =?UTF-8?q?K=C3=A9vin=20Le=20Gouguec?= , Thiago Jung Bauermann Subject: [PATCH v2] Refrain from asking debug stubs to read invalid memory Date: Tue, 3 Sep 2024 15:00:45 +0200 Message-Id: <20240903130045.2957421-1-legouguec@adacore.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240318161955.668163-1-legouguec@adacore.com> References: <20240318161955.668163-1-legouguec@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Some stubs take exception to this. For example we observe RTEMS's libdebugger freezing when asked to examine address zero on aarch64/xilinx_zynqmp_lp64_qemu. As of 2024-02-02 "gdb, types: Resolve pointer types dynamically" (f18fc7e56fb) this happens as early as 'target remote'. Ordinarily we would be greeted with… _User_extensions_Thread_switch (executing=0x0, heir=) at […]/cpukit/include/rtems/score/userextimpl.h:382 … but now, as language_defn::read_var_value calls resolve_dynamic_type with a "dummy" address and value, resolve_dynamic_type_internal receives a similarly "dummy" addr_stack, and attempts to read memory address zero: guard against that. Reviewed-by: Thiago Jung Bauermann --- New in v2: applied Thiago's suggestion to add an 'else' branch. gdb/gdbtypes.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c index f39fe3de6a4..856eff4d166 100644 --- a/gdb/gdbtypes.c +++ b/gdb/gdbtypes.c @@ -2804,8 +2804,10 @@ resolve_dynamic_type_internal (struct type *type, if (addr_stack->valaddr.data () != NULL) pinfo.addr = extract_typed_address (addr_stack->valaddr.data (), type); - else + else if (addr_stack->addr != 0) pinfo.addr = read_memory_typed_address (addr_stack->addr, type); + else + pinfo.addr = 0; pinfo.next = addr_stack; /* Special case a NULL pointer here -- we don't want to -- 2.34.1