From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 803113857C69 for ; Tue, 11 May 2021 06:25:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 803113857C69 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x430.google.com with SMTP id m9so18886977wrx.3 for ; Mon, 10 May 2021 23:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ttmVVPATa17V9cG+0Fk5ZSbUdbHaK3aTxfBX3xgQi8g=; b=CEqEwy/p6nrf4egxFXubtMM+DSzudbooXz9pgMcswA+bNJzP4Aw9kpeeXQyyRM9zbT kuAaBsBhxP8ZwDhYoFKY0icXkw9UkiBStVR4k4XDV8iDerlm4/0t0SDyZ8geYFDbcn+3 rCs7+0uYsp23/BISxK4Xs6jk6aRXSlM1Ny0cOMGw1P7VMaxladF+4UP7o8OGGzepWrTs U7gEELquco/O2aCR/Me2K1pBD+KPGItZhYPDxX8KYmIBiUt5SpYFWywB4L/Tv2uz5YOj fcGf1i9aHyU3pJRqC1DMI7DSy6WV4HL13ZGx64xgdCiaFzatezSqiSDVvNsCslFiv2BV 7k3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ttmVVPATa17V9cG+0Fk5ZSbUdbHaK3aTxfBX3xgQi8g=; b=iuDkLWLLyZGNsDvf7tyYnFe+j6siV1/f16mS150wPlUNtc3BzHoeqpRFXXvjq2JNl0 d1iHq57Gfjmxz3CdfN6n79pMV+n9uyk7l+f6L4zIq7JwuzvJVZuQb3NbF9GJoXXWpK/L uMNG48zmuxnl62kHm3k439yDZiPDaAJFutvp9yE+aXHbEDJK62l7xnZyrPBRCa5L4gNL ZZQrJVjjxsP06QfUB6gRx5rhRUZ/H55g/TRkwWv+Y1X//28LmKWHGL9qOdKOwgjsg55f hV4EZ4TmAevsF7qAplf+E6BsDr0l369T66dPTwHhnejCyD5g9NehczjDIm9czMRmeZzR SbKQ== X-Gm-Message-State: AOAM5334xCgNiCbKqd22SjFEIrw78Fjq39fjrwn7vvTLTO+bf+bCHhjD Tbty69kYrmFp4dWtv3or8nWCHA== X-Google-Smtp-Source: ABdhPJy27ngeotS9arXH75cMm2x9YLOflspE9LEbnJ9SYiKEXDWrPhtfj9NOOoq3YGiXwHecBx857Q== X-Received: by 2002:a5d:544d:: with SMTP id w13mr34916582wrv.273.1620714338613; Mon, 10 May 2021 23:25:38 -0700 (PDT) Received: from localhost (host109-151-46-70.range109-151.btcentralplus.com. [109.151.46.70]) by smtp.gmail.com with ESMTPSA id f25sm26478638wrd.67.2021.05.10.23.25.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 May 2021 23:25:38 -0700 (PDT) Date: Tue, 11 May 2021 07:25:37 +0100 From: Andrew Burgess To: "Jose E. Marchesi" Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 0/1] Integrate GNU poke in GDB Message-ID: <20210511062537.GT6612@embecosm.com> References: <20210510151044.20829-1-jose.marchesi@oracle.com> <9f1f3ee3-f31e-2941-3f6b-f54552f5c16b@polymtl.ca> <87r1ieuzcf.fsf@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r1ieuzcf.fsf@oracle.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 07:24:42 up 7 days, 19:19, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-6.1 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 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 06:25:43 -0000 * Jose E. Marchesi via Gdb-patches [2021-05-10 22:07:44 +0200]: > > Hi Simon. > Thanks for the feedback. > > >> A few notes: > >> > >> - The poke support is optional, and built if specified with > >> --enable-poke at configure time. > > > > If I look at this reference [1]: > > > > --enable-*/--disable-* arguments > > > > The arguments starting with --enable- prefix are usually used to > > enable features of the program. They usually add or remove > > dependencies only if they are needed for that particular feature > > being enabled or disabled. > > > > --with-*/--without-* arguments > > > > The arguments starting with --with- prefix are usually used to > > add or remove dependencies on external projects. These might add > > or remove features from the project. > > > > I don't find this super clear, as we could always see it both ways. I > > want to enable the support for running Python code, so I use > > --enable-python, which has the side-effect of pulling libpython. Or I > > want to make my project depend on libpython, so I use --with-python, > > which has the side-effect of adding the "can run Python code feature" in > > my project. > > > > But most of our dependencies on external libs are expressed with > > "--with", so I'd go with "--with-poke". > > Ok, I will change it :) > > >> > >> - Eventually we will probably want to ship some prewritten Poke > >> code in a pickle gdb.pk. Would $pkddatadir/poke/ be a good > >> location for Poke code distributed with GDB? > > > > So, /usr/share/poke? > > > > Would gdb.pk contain some poke code that gdb would use itself, or is the > > goal to make that poke code available to other libpoke users (like the > > poke cli)? > > > > If it's code that is only meant to be used by gdb, it would make sense > > to have it in GDB's own data dir (/usr/share/gdb/poke). A bit like gdb > > has some Python code it uses for itself, in /usr/share/gdb/python. > > Yeah that makes sense, /usr/share/poke for the first case, and > /usr/share/gdb/poke in the second case. > > >> > >> And a few questions: > >> > >> - Where am I supposed to cleanup and shut down the incremental > >> compiler when GDB exits? I looked but I cannot find a > >> counterpart to _initialize_FOO, like _finalize_FOO. > > > > See make_final_cleanup. Or, you can use an std::unique_ptr > > specialization that calls your finalize function on destruction. If > > that object is global (or static within a function), it will be > > destructed when the program (GDB) exits. There was a discussion about > > exactly this but for debuginfod recently: > > > > https://sourceware.org/pipermail/gdb-patches/2021-May/178578.html > > That unique_ptr approach should work. Will take a look to that > discussion and DTRT. > > >> - There are many global parameters that can be configured in the > >> poke incremental compiler: the numeration base used when > >> printing values, the global endianness, a cut-off value for how > >> many array elements are printed, and the like. Reasonable > >> defaults for them are set in `start_poke', but I would like the > >> GDB user to be able to change these settings. I could add a > >> `poke-set SETTING [VALUE]' command, but I was wondering whether > >> there is a better way, like a global register of settings > >> already in GDB? > > > > Without more knowledge of how this all works, I'd say that > > > > set poke PARAM VALUE > > show poke PARAM > > > > would be more GDB-ish. > > Yes that's what I had in mind :) > > > Is there a way for GDB to list all poke's parameters at startup, so it > > could register them all as a "set/show" command in GDB? > > Yes, that is certainly possible. > > > As a result, the user could do "set poke " to see all > > possible parameters, which I would find really nice. > > Definitely! > > > Although if you think we might ever need to add some GDB parameters that > > are not poke parameters, but parameters about how GDB uses/integrates > > poke, then there is a chance of clash in the "set poke" namespace. In > > that case, we could put all poke's parameters under > > > > set poke parameter PARAM VALUE > > show poke parameter PARAM > > > > This way, we could have distinct "set poke parameter foo ..." and "set > > poke foo ...". > > Where is the interface to add the settings? You'd want the add_setshow_* functions declared in command.h. Calls to these are usually added to an appropriate _initialize_* function. Thanks, Andrew