From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by sourceware.org (Postfix) with ESMTPS id EA0EE3858C33 for ; Wed, 19 Jul 2023 14:41:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EA0EE3858C33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-7836164a08aso374556639f.1 for ; Wed, 19 Jul 2023 07:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1689777699; x=1692369699; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=HCjXwlfTcoHB94bpAU5KGiqjkr0DtT5IgmNOK5UYt38=; b=KOiRuDt7ZNjOJecPl+I0VUtSkSR0f6DGahOYBmwnyV3AoT/cFynZA+rm5nImcaQYZo zjH04C6BLrktnZy1nbLiTyuUaXrkOwkRzZn02N/5oUzYCusTF0UfHk2hdL3hUoyvwC1V Cc9EsLa9ArqaUOj14QuuDwSL7KjyVUlcGkiFFYY3oebR1UTPQ8YpoEUd1nJXkMU+xP+i QpdbLx36U+3umAzku0VHO4uJCfNnPTANgevk17/tSVxODhX5S8imdqveEF4XH0+aoipo KqmV60PkCmd1EQj7DMu/YMSmSi9mzAwfgrklWqZzU46mQo2NA1O+nbhLceeAjbBGMmbW S9Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689777699; x=1692369699; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HCjXwlfTcoHB94bpAU5KGiqjkr0DtT5IgmNOK5UYt38=; b=dw/cV4/Ypk0mf66tnOe4T10oFCLy8BOn59Pc7CBUDkn9Xo5RhkFu/n5u9y9C01suIq 5JOulm2HwDhZXRGeK4b13uQHwhV8mwNrT5piBg0Ec1hU1wd1p6J3Q1hRchgDQ2IWOBjh HD8iaOpGFIB2azdABJXH40gLjMIwUULtUKMbmOn1FWtujD89dbi3Bu6mixCIcRSDtJEb IQEQFGb3g8dbr3+432SYnkS70XCRPD0uFssw2zsFT8P8VIhP4yX+jmIVLJG0koQsosJ/ +Da6w8laYscUibppU8WtTO44rs/sP0uUdqDwdpBApjOLXSNbJVqpshRZF78PgPh/SnnZ YSdg== X-Gm-Message-State: ABy/qLYsFmkgtui0i/FutSWHlNTFdvLJ6NcHBOLmiJSPev7SGLw1XsTF y0spbjtC6mzmRK2PIZLiPQZoWg== X-Google-Smtp-Source: APBJJlGFvOnK3OFUFfNYBZFKO+oGwdi6QhtCaY0xJ6uyQxY+B5vH53nN3A+ClbSYSedKLN8A8UywrA== X-Received: by 2002:a5d:9cce:0:b0:783:67a3:a69f with SMTP id w14-20020a5d9cce000000b0078367a3a69fmr5884377iow.18.1689777698808; Wed, 19 Jul 2023 07:41:38 -0700 (PDT) Received: from murgatroyd (75-166-135-140.hlrn.qwest.net. [75.166.135.140]) by smtp.gmail.com with ESMTPSA id a17-20020a02ac11000000b0042b265bf3besm1280224jao.115.2023.07.19.07.41.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 07:41:38 -0700 (PDT) From: Tom Tromey To: Simon Farre Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH v1] gdb/DAP Introduce new methods to to Pretty Printers References: <20230625092116.252503-1-simon.farre.cx@gmail.com> <87jzv3o8ck.fsf@tromey.com> <02d2c008-224a-821e-80d4-6f2f9a81e532@gmail.com> X-Attribution: Tom Date: Wed, 19 Jul 2023 08:41:37 -0600 In-Reply-To: <02d2c008-224a-821e-80d4-6f2f9a81e532@gmail.com> (Simon Farre's message of "Mon, 17 Jul 2023 22:52:15 +0200") Message-ID: <87351km09q.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Simon> We could go the c++ standard library route here and define silly Simon> (guard) names for everything we do, going forward. gdb didn't reserve those, either. Probably we should just add a second registration approach, one that allows for future upgrades to the API. It's just more work. For DAP we could instead go the other route, and change the fallback printers to use a fuller API, and then use a shim for existing printers. >> These are exposed to Python as struct types, but we'd like to present >> them as array types over DAP -- which is what is done for the CLI (via >> special cases in the printing code) and also for MI (via varobj, though >> I haven't actually implemented this for Rust yet). Simon> I don't understand this part, I wrote a the documentation example, Simon> that behaves like an dynamic array, Simon> where pretty printer makes use of it's intimate knowledge of the Simon> length, because I specifically had languages Simon> like Rust in mind (or any other type of dynamic data). Simon> Or do you mean that it should automatically understand when Simon> it's a built in type, in the language? That would be nice. But would Simon> that not introduce scope issues, like at what point do we stop? gdb already does this. I think the decisions are made per language, but the general rule is that anything that can be created by the compiler is normally supported by gdb, but anything in a library is expected to be described by DWARF. In Rust this mostly amounts to handling slices, but Ada has more constructs that need special handling. Simon> Wouldn't we have to 1st class-implement every language that has a Simon> novel idea of representing (its own) standard data types? Or are for Simon> instance Simon> Rust slices represented specifically as a special type in DWARF that Simon> we can recognize? Normally the problem cases here are ones where there is a difference between their representation in DWARF (e.g., a Rust slice or an Ada unconstrained array are really struct types) and their meaning in the language (these are both array-like constructs). It's important that gdb have access to both of these things. For example, for a while GNAT could emit these kinds of arrays using complicated location expressions -- but that makes it impossible to create a new instance, because "undoing" the expressions is hard. Simon> Either way, having a "smart pretty printer" sounds good, for the use Simon> cases you've described, Ada strings, Simon> Rust slices, etc - but my biggest question is how would we extend that Simon> to arbitrary client code? My thinking for the route forward is: 1. Add a new pretty-printer API that is clearly extensible and change the core to use it. Old pretty-printers can be wrapped in shims. 2. Add support for these array-like objects to gdb.Value or maybe gdb.Type. The idea here is to let Python be able to access the same things that gdb already knows. Tom