From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 89C043858C27 for ; Mon, 10 May 2021 18:39:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 89C043858C27 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 14AId9gR026263 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 May 2021 14:39:14 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 14AId9gR026263 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 372CA1E813; Mon, 10 May 2021 14:39:09 -0400 (EDT) Subject: Re: [PATCH 0/1] Integrate GNU poke in GDB To: "Jose E. Marchesi" , gdb-patches@sourceware.org References: <20210510151044.20829-1-jose.marchesi@oracle.com> From: Simon Marchi Message-ID: <9f1f3ee3-f31e-2941-3f6b-f54552f5c16b@polymtl.ca> Date: Mon, 10 May 2021 14:39:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210510151044.20829-1-jose.marchesi@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 10 May 2021 18:39:09 +0000 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, 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: Mon, 10 May 2021 18:39:19 -0000 On 2021-05-10 11:10 a.m., Jose E. Marchesi via Gdb-patches wrote: > Hi GDB people! > > The patch below integrates GNU poke (http://jemarch.net/poke) in > GDB by mean of libpoke. > > It allows the GDB user to execute Poke code from within the > debugger with access to the target memory, types and values. Awesome! I'll try to answer a few of your questions, without having read the patch itself. > > 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". [1] https://autotools.io/autoconf/arguments.html > > - The poke support requires libpoke from git master (which will > become poke 2.x in a few months) since it uses some interfaces > that are not available in the released poke 1.x series. > > - Sorry for what is probably an atrocious mixture of C and C++ > idioms. I avoid C++ like the pest, but I am all willing to try > and write proper C++ for this integration. No problem, we can help you with that. > > - 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. > > 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 > > - 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. 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? As a result, the user could do "set poke " to see all possible parameters, which I would find really nice. 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 ...". > > - I am using target_{read,write}_raw_memory to access the > target's memory. What is the difference between the raw and > non-raw accessors? >From target_read_raw_memory's doc: /* Like target_read_memory, but specify explicitly that this is a read from the target's raw memory. That is, this read bypasses the dcache, breakpoint shadowing, etc. */ So, it bypasses a cache in GDB (not sure why that's important). But most importantly, the non-raw version will hide the software breakpoint instructions, it will replace them with the original memory contents, whereas the raw version will not. Let's says that the user decodes some memory where a breakpoint is, using target_read_raw_memory will return the memory contents with the breakpoint instruction. I think that most of the time, the user will actually want to decode the original contents, so using target_read_memory would be better. And if you write memory with target_write_raw_memory, I guess you can end up overwriting a breakpoint, so that's not good. So I'd probably use target_write_memory. > > - How can I demangle C++ identifiers? And how can I detect when > a given type is a C++ one that needs demangling? I think that we usually rely on the language of the compilation unit, as given by DWARF, to know that a symbol has a C++ mangled name and needs demangling. But otherwise, see the gdb_demangle function. Simon