From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aL0/F4Yt2GYWxR8AWB0awg (envelope-from ) for ; Wed, 04 Sep 2024 05:51:02 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=SATVn+RJ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 364D11E353; Wed, 4 Sep 2024 05:51:02 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-12.8 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIMWL_WL_HIGH,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 E80BA1E05C for ; Wed, 4 Sep 2024 05:50:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 73A14385F028 for ; Wed, 4 Sep 2024 09:50:59 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id C22AC3858CDB for ; Wed, 4 Sep 2024 09:50:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C22AC3858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C22AC3858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725443439; cv=none; b=LzuAmAmQMrY0fNEC/LEbcVKnSjWEcBTMKLNLQLlIjL9mq8rOJMPTTYrRXfoHIjD9k4INZf47OxpDkb/W37BAxseCYpVdGYCsK2JQl1kHT2RYUz7EUoYMU6lzlB8ZPRGeSXf8xoRHO+8aBJzcXJRqTpVlEduVLZQvbqal+EXsR5A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725443439; c=relaxed/simple; bh=s5ezyjHW7BPrnMsepzs/SBRVFdz9r9V7rpg7d2ZEH0k=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=FjkZ91dOVsZUz/f2/hw8eHh/GuB6fuIv8U2z7Uhz0DA+n9pBWBd1GCiU+x9fEZoEfFf/lUzLVFw8//cQRUvOiZcKLbOiomobkb6aOBLpz+p3qGpLSCtC+Pklx7TtA9vfSbUd9lhrNrTv1EXDG9onyUDhZcWa0Lnv8tAcfgW3QFE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725443436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HGumLgpFCURcaNzIYWlLXKUj+Oo1zwBYnb66VfznVV0=; b=SATVn+RJRW1UqPsfIOgg/SdzXJ4y+RQDQggaX0ihHdoaG1Vxo8vI8a5hcV9Gnirf93uwlE zYFQBA2kcoKLYM18qd7h/5Vc5L9xT5Mqrq1gRNxzCD6lp4v9o4XEqE4ybexKjx7Cm4hgpV 6geE7hxZsUlYwkT4QoR6/FSpK8UAj2U= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-140-zIC7UR2ePve1yTEblP-nGg-1; Wed, 04 Sep 2024 05:50:35 -0400 X-MC-Unique: zIC7UR2ePve1yTEblP-nGg-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-42bbf928882so44263325e9.1 for ; Wed, 04 Sep 2024 02:50:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725443434; x=1726048234; h=content-transfer-encoding:mime-version: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=sRStVZSTyPfZnbf1lRX87NL4jQ/cUgGQiinHsA7NShE=; b=VhGMPM+1VqFJKKj9ZoLOI5nb7abYkVf9kPjdmpFGsdWnV6SYPHeyaO8jFVvMUA5uHs dgeoMZLDK6mzTGvNdR2xGNXBbI3mYlLA4HM3ldL6uG9w41nVsiac8Jau4E+5/hy9jZxg syFA0vq8tjkLZ/xsPR+e6VUFaPHm9n6f6CnxKSnshy0EV2BG0kSJTgNyYf1RgPoiBqhS 5KTt1aLMS+GRjHsiGeAPAW8oUSnRvZmXBPXZlxPkaNqzbHUOhv5HBJJZpb0Auy8f4ACz rZPHkIMYWhTDkqgrwBIrl3LW95j/Tf3WvJE4xA6wWV0qAYIxPgrexNCKdf4t0C5ANyIQ hzDA== X-Forwarded-Encrypted: i=1; AJvYcCWKSFWO7Uxdo09zWlo9zbAwZCvDR2e1y1r2nuc2ezHRAeI06ceOK1nABDOfpMRJ+KCvL1q9T/gq1DJxWA==@sourceware.org X-Gm-Message-State: AOJu0YwsLexSCbQ0WloFHEggPx2UBzDCJwBdE55y88+iv15/myORFry8 6PDcqyBFa7SP1+0NDf4YXFrdbXrnU+QhElwjD/lMPRAmfjUjwa2LX7bwLN5S62VlSCcjyUWrVT5 54l3hz23ueYSLeJDccQgNE2S0CImwYtkKhirjxRkJiLTtQYiwLmNHbKRGKMo= X-Received: by 2002:a05:600c:19cc:b0:429:e637:959e with SMTP id 5b1f17b1804b1-42c8de79a90mr26756995e9.10.1725443433935; Wed, 04 Sep 2024 02:50:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IED9BGFlog2zXJWtPv6JoD53eRZRmasqE0Edu4bve3gflOnQvBG1A/cVs0BZENF2AleM3tWDg== X-Received: by 2002:a05:600c:19cc:b0:429:e637:959e with SMTP id 5b1f17b1804b1-42c8de79a90mr26756625e9.10.1725443432718; Wed, 04 Sep 2024 02:50:32 -0700 (PDT) Received: from localhost (178.126.90.146.dyn.plus.net. [146.90.126.178]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-374c9487bebsm8626762f8f.94.2024.09.04.02.50.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 02:50:32 -0700 (PDT) From: Andrew Burgess To: =?utf-8?Q?K=C3=A9vin?= Le Gouguec , gdb-patches@sourceware.org Cc: =?utf-8?Q?K=C3=A9vin?= Le Gouguec , Thiago Jung Bauermann Subject: Re: [PATCH v2] Refrain from asking debug stubs to read invalid memory In-Reply-To: <20240903130045.2957421-1-legouguec@adacore.com> References: <20240318161955.668163-1-legouguec@adacore.com> <20240903130045.2957421-1-legouguec@adacore.com> Date: Wed, 04 Sep 2024 10:50:31 +0100 Message-ID: <87jzfru4rc.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 K=C3=A9vin Le Gouguec writes: > 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=E2=80=A6 > > _User_extensions_Thread_switch (executing=3D0x0, heir=3D) > at [=E2=80=A6]/cpukit/include/rtems/score/userextimpl.h:382 > > =E2=80=A6 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. The problem with this approach is that there are targets out there that can read from address 0, so detecting 0 and handling it differently as you propose is not the right approach. 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. Ideally, if we wanted to support not reading memory then we should carry around a std::optional instead of just a CORE_ADDR. As for the target freezing when trying to read from 0 ... that's 100% a target bug. If the actual h/w doesn't support reading 0 then the controller (e.g. OpenOCD) should take care of filtering out the access requests. Or in your case (qemu) then the emulator should just be fixed to return an error on these accesses. The other option is for the remote to provide GDB with a memory map[1]. 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: type =3D resolve_dynamic_type (type, view, /* Unused address. */ 0); The problem you see is that these end up calling: read_memory_typed_address (addr_stack->addr, type); in resolve_dynamic_type_internal. Now as far as I can tell this function will throw an exception if the read fails. 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. Which makes me think: can't we write a test case for this bug? Thanks, Andrew [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Memory-Map-Forma= t.html#Memory-Map-Format > > 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, > =09 if (addr_stack->valaddr.data () !=3D NULL) > =09 pinfo.addr =3D extract_typed_address (addr_stack->valaddr.data = (), > =09=09=09=09=09=09 type); > -=09 else > +=09 else if (addr_stack->addr !=3D 0) > =09 pinfo.addr =3D read_memory_typed_address (addr_stack->addr, typ= e); > +=09 else > +=09 pinfo.addr =3D 0; > =09 pinfo.next =3D addr_stack; > =20 > =09 /* Special case a NULL pointer here -- we don't want to > --=20 > 2.34.1