From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 8863D3858D28 for ; Mon, 17 Jul 2023 20:52:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8863D3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-4fb7589b187so7937818e87.1 for ; Mon, 17 Jul 2023 13:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689627137; x=1692219137; h=content-transfer-encoding:in-reply-to:cc:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=TH+lHN5j07R9wb5YWPlYaY+aqV2vsPaUkvbQP8/aRtA=; b=kBT3Pe1BCRchy09ixEtT4SmHBrObVztXwrftHtk49iLYg1QX4ggV3V+oHFPRhR1AbG v4q3luF57nhUs+uD9nMY95SkViSCvbnosLvK2KWx5qPK3qgOU/nbHUmjFeOuqQ9aqO/g m+j9G4F4Kw0r4AOvEJ/DLoda8lHq6trbCv/KKhX0+0aDpTBFzXXvI8jZEJRRjKXt5AtK 9aStkh+hSNIHLUA76H2CQjW/kRePgun0dOWoFGaqTWKiAVLITgPA36cwmyq+7vU3Ewo5 FOLZWDsiv69oDncuiwjVVChZnxN3w+JhXAXuL/4JRDr8TEeSrOnrnysnIlLE0pawMUde Yu9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689627137; x=1692219137; h=content-transfer-encoding:in-reply-to:cc:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TH+lHN5j07R9wb5YWPlYaY+aqV2vsPaUkvbQP8/aRtA=; b=jqemHD4ZLNb5gMOiV42hWP74yH7pp6F3Xc8LAIoEHxCZCBxj6U2mUP7PBqCmXwPvTn DEZb12fjUozAwqOk1/WorMI3jQVOxjT4s13xHLw2Mi3+ksP6OjxZcXNtcluWHfc3jOA7 ZgOR/UR+jHDscFBH193BxlYwVwoQ5dGBiN8d6t8Wvj0Z/YRLkMP+Krrm0QvBPm4twJvg iwbWr/riPciQVbk3p/GnHxGvJ7zuOFLLgGjJGf/wUc54gwnyNGQljHJVpDQhQYcsgrpr 1fIPE1zEnbtvsztr2acRmBoQKYCnObnu8Tl8+B3YbCNxJcOeOs6LNoKr/yXrDIhfUCXp cFWw== X-Gm-Message-State: ABy/qLbFyMhVfwVK2g8HF1X3pdluYAJ2XcAP5hJhPll0fD/XLyQLGEuO 8T4HM6aVlc1MTh2Vadsg9RuV8qGUde0= X-Google-Smtp-Source: APBJJlFMNnMRZfJ/Kp7916aAG6HQIrwdZmcTrHa3VrFkjMbiwzKfgF3qgaTAFxBeRKkh65ZnkipOhA== X-Received: by 2002:a19:9117:0:b0:4f8:666b:9de4 with SMTP id t23-20020a199117000000b004f8666b9de4mr8067861lfd.20.1689627137001; Mon, 17 Jul 2023 13:52:17 -0700 (PDT) Received: from ?IPV6:2001:2044:c7:5500:5637:6b43:7745:198c? ([2001:2044:c7:5500:5637:6b43:7745:198c]) by smtp.gmail.com with ESMTPSA id eo17-20020a056512481100b004fb75943aa0sm80500lfb.196.2023.07.17.13.52.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Jul 2023 13:52:16 -0700 (PDT) Message-ID: <02d2c008-224a-821e-80d4-6f2f9a81e532@gmail.com> Date: Mon, 17 Jul 2023 22:52:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v1] gdb/DAP Introduce new methods to to Pretty Printers To: Tom Tromey References: <20230625092116.252503-1-simon.farre.cx@gmail.com> <87jzv3o8ck.fsf@tromey.com> Content-Language: en-US From: Simon Farre Cc: gdb-patches@sourceware.org In-Reply-To: <87jzv3o8ck.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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: Hi Tom, thanks for your input! > The reason stems from a mistake we made early on when adding Python to > gdb -- when adding pretty-printers, we weren't very careful about > letting people know that we might add more methods to the printers. > > This means existing code is free to use any name on the printer objects, > except the few we documented. I'm not sure num_children or > children_range are used anywhere -- but they might well be. > > Of course it's not very hard to fix this in printers. However, it's bad > to ship a new gdb that breaks people's setup. We've tried pretty hard > to avoid this. We could go the c++ standard library route here and define silly (guard) names for everything we do, going forward. So; def __children_range, def __num_children. If it's good for C++ standard library developers, it can be good for us as well ;).  Even though it's a tried and true approach it's not one that I'm much fond of, but we could do that. > 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). I don't understand this part, I wrote a the documentation example, that behaves like an dynamic array, where pretty printer makes use of it's intimate knowledge of the length, because I specifically had languages like Rust in mind (or any other type of dynamic data). Or do you mean that it should automatically understand when it's a built in type, in the language? That would be nice. But would that not introduce scope issues, like at what point do we stop? Wouldn't we have to 1st class-implement every language that has a novel idea of representing (its own) standard data types? Or are for instance Rust slices represented specifically as a special type in DWARF that we can recognize? I think with the Python approach we leave more room for flexibility, than we do closing the PP stuff behind "MI-doors" as it were. I also have a pet peeve against MI, so I *really* don't like that, just based on personal preference. Besides, going the MI approach, excludes anyone who actually wants to write a (performant) pretty printer for their own container, doesn't it? I don't think we can accept 100ms response times for trivial data, when pretty printers are involved (and if libstdc++ pp is involved, it crashes and burns, making debugging using DAP impossible as previously discussed). Either way, having a "smart pretty printer" sounds good, for the use cases you've described, Ada strings, Rust slices, etc - but my biggest question is how would we extend that to arbitrary client code? Never mind about the caching-stuff I said, that can be left to any DA-implementers that wrap GDB's DAP, if they choose to live on the wild side. I think closing the gaping performance hole is of much more importance. Simon