From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 501523858D33 for ; Sat, 7 May 2022 19:07:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 501523858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mad-scientist.net Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=mad-scientist.net Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:54615) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nnPmL-0001dS-Ho for gcc-help@gcc.gnu.org; Sat, 07 May 2022 15:07:48 -0400 Received: from cmgw10.mail.unifiedlayer.com (unknown [10.0.90.125]) by progateway3.mail.pro1.eigbox.com (Postfix) with ESMTP id F323D100478A5 for ; Sat, 7 May 2022 19:07:13 +0000 (UTC) Received: from box5922.bluehost.com ([162.241.30.80]) by cmsmtp with ESMTP id nPlpn8HzQQs3CnPlpnBqbb; Sat, 07 May 2022 19:07:13 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=A+Opg4aG c=1 sm=1 tr=0 ts=6276c361 a=u+82WREdhvUKZ7QTvcqjvQ==:117 a=u+82WREdhvUKZ7QTvcqjvQ==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=IkcTkHD0fZMA:10:nop_charset_1 a=oZkIemNP1mAA:10:nop_rcvd_month_year a=3EOfIcITIxQA:10:endurance_base64_authed_username_1 a=pBbsfl06AAAA:8 a=Af8ziWGgQm9v6Fg6eu4A:9 a=QEXdDO2ut3YA:10:nop_charset_2 a=Pykvx6M6Og9ney6Qs4Vj:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mad-scientist.us; s=default; h=MIME-Version:Content-Transfer-Encoding: Content-Type:References:In-Reply-To:Date:Cc:To:Reply-To:From:Subject: Message-ID:Sender:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aVTwD4u6wXUH49/CAtGuUkpw2LXWPbDY6cSCw3vfhGU=; b=vlfsYQL+ExcIdwLuO/HJYXZCZT SlxyLG9QULbm1kIcQ8KewKEM1rnimWqdXOmoF+EgHQsT0CTiJGYmUrx7HVZgFUGK6fGWqllY5EVmU JXLnZNv+TPtW3XlPljKvijWD9; Received: from static-11-191-147-69.axsne.net ([69.147.191.11]:10404 helo=[10.200.118.216]) by box5922.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nnPlp-000zcN-5W; Sat, 07 May 2022 13:07:13 -0600 Message-ID: <222e7c9b9ac74aa886c1501792e677a0dfa1f268.camel@mad-scientist.net> Subject: Re: Help using the GDB C++ STL pretty-printers / xmethods From: Paul Smith Reply-To: paul@mad-scientist.net To: Jonathan Wakely Cc: "gcc-help@gcc.gnu.org" Date: Sat, 07 May 2022 15:07:12 -0400 In-Reply-To: References: <5568db74d0acb198a3e8121ee75e3cfa02ea0c6f.camel@mad-scientist.net> <453082091.802975.1651922375216@mail.yahoo.com> Organization: Please remain calm--I may be mad but I am a professional! Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1 (by Flathub.org)) MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5922.bluehost.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mad-scientist.net X-BWhitelist: no X-Source-IP: 69.147.191.11 X-Source-L: No X-Exim-ID: 1nnPlp-000zcN-5W X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: static-11-191-147-69.axsne.net ([10.200.118.216]) [69.147.191.11]:10404 X-Source-Auth: paul@mad-scientist.us X-Email-Count: 1 X-Source-Cap: bWFkc2NpZTE7bWFkc2NpZTE7Ym94NTkyMi5ibHVlaG9zdC5jb20= X-Local-Domain: yes Received-SPF: pass client-ip=69.89.25.95; envelope-from=paul@mad-scientist.net; helo=gproxy1-pub.mail.unifiedlayer.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, SPF_HELO_PASS, TXREP, T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2022 19:07:53 -0000 On Sat, 2022-05-07 at 16:35 +0100, Jonathan Wakely wrote: > On Sat, 7 May 2022 at 16:08, Paul Smith > wrote: > > Thanks for the reply.=C2=A0 I should have mentioned this; what I do is: > >=20 > > =C2=A0 python > > =C2=A0 from libstdcxx.v6 import register_libstdcxx_printers > > =C2=A0 register_libstdcxx_printers(None) > > =C2=A0 end >=20 > Why are you doing this by hand? That should not be necessary. Well I have this in my init file so I don't really enter it by hand.=20 But are you implying that it should somehow happen without having to do anything at all... how does that work? Do you mean, that my distribution should have set things up so that it happens automatically? Or that somehow GDB should "find" these macros on its own? Note I am building/installing my own GCC and GDB so maybe I just haven't put everything in the right places. > > Just to clarify are you saying that one or both of the methods I've > > tried (using * or -> operators) _should_ work, and that they do > > work for you when you try them? >=20 > Yes. OK, I've discovered what's going on. Apparently for some reason the ability to show the values doesn't happen immediately. When I attach to a process and it's sitting in a sleep somewhere in the C runtime like this: (gdb) bt #0 0x00007f804634e26f in clock_nanosleep () from /lib/x86_64-linux- gnu/libc.so.6 #1 0x00007f8046353ef7 in nanosleep () from /lib/x86_64-linux- gnu/libc.so.6 #2 0x000000000097a3c9 in SignalHandler::sleepUntilSignal (this=3D, response=3D..., timeoutMs=3D) at SignalHandler.cpp:205 #3 0x0000000000960e64 in Engine::main (this=3D0x7f8045f0f000) at Engine.cpp:1374 #4 0x000000000098fbdf in Engine::runMain (this=3D0x7f8045f0f000) at Engine.cpp:793 #5 0x000000000095f907 in main (argc=3D, argv=3D) at main.cpp:59 so my current frame is #0, then I run a python function I wrote that shows a bunch of info about this process and sets a convenience variable for the main pointer $mp, then I try to use it I get the errors I showed earlier: (gdb) p $mp->mgr->initialized One of the arguments you tried to pass to operator-> could not be converted to what the function wants. but, now if I change my frame (to one of my frames... it doesn't help to go to frame #1 above) it works fine: (gdb) fr 2 #2 0x000000000097a3c9 in SignalHandler::sleepUntilSignal (this=3D, response=3D..., timeoutMs=3D) at SignalHandler.cpp:205 205 ::nanosleep(&interval, NULL); (gdb) p $mp->mgr->initialized $1 =3D true Now I can go back down to frame 0 and it still works: (gdb) fr 0 #0 0x00007f804634e26f in clock_nanosleep () from /lib/x86_64-linux- gnu/libc.so.6 (gdb) p $mp->mgr->initialized $2 =3D true I can't find anything in the GDB docs about this but I guess it's a question for them, as to what's happening here. > > I'm not talking about printing things per se, I'm talking about > > writing my own python macros that help me examine my own data > > structures, which are built with STL types. > >=20 > > For example I have a complex structure that uses std::vector, > > std::list, std:unordered_map, unique_ptr, etc. and I want to write > > my own methods that examine these structures, either to print them > > in a different way (not just the standard pretty-printer output) or > > whatever. >=20 > That sounds useful, but it's unlikely anybody else is going to > provide it. If you want it, you get to build it :-) (sorry please replace "macro" with "Python function" everywhere in my email... I will try to do better) I'm pretty sure that's the same answer I got last time I asked :). I just don't have the time or, probably, the knowledge of the STL implementation I would need to do this well. But I would be happy to work with someone, including writing some code, designing some features, etc., if anyone else were interested. What I would really like to have are two things: (a) iterator classes that I could instantiate from my python functions when I need to iterate through an STL type. So if in my class I have "std::list fooList" and in my python functions I have a python variable "fooList" which refers to this object, I would like a way to write something like: for elt in StdForwardIterator(fooList): Map iterators could return a tuple, etc. I don't know if it makes more sense to create individual iterator classes like above, or to implement Python classes that wrap types and provides Pythonic access by implementing Python special methods (so that an std::unordered_map object could be treated like a dict or whatever). (b) Ways to access the contents of containers like unique_ptr, shared_ptr, etc. from python functions. So if in my class I have "std::unique_ptr fooPtr" and in my python functions I have a variable "fooPtr" which refers to this object, I would like a way to retrieve a gdb.Value containing its pointer.