From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 412A53857C4A for ; Sun, 8 May 2022 08:16:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 412A53857C4A Received: by mail-wr1-x42d.google.com with SMTP id q23so15537654wra.1 for ; Sun, 08 May 2022 01:16:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2hZ+zVxCOKlIarJPYI5PBsid7/pZrda75cuK2wzqCq8=; b=EdRheSWCCstUbO/yu+curHIruBO73IFowQxYwryNu51b3Tq15uUVqQe2aS8xGYgE6n 1LAGz+AnvpjDT2b0diZBznKb6GPY7p8Of42S56rv/h0g9BcGQZGbKKZ/lnNOsk652GMH mtmmk5qTyZVObdfOwMoT+RNHkA4cSrC7kNpttDVoxhmMdcTsFzqd/6AqbHQ0fpd8yvvN yeWekrsEVlJjswyPu3orRxaM/+G2lKDk7wJ9g2TaQY0bpY37K7N/fZcAMAGHSv2Zpx/y S2cBZ79MMJzj+YaKNOSQ3nec9jgOygQEoLl25weA7az9Xykt8llfmSSxzD7270NaANvf vI7A== X-Gm-Message-State: AOAM530uJpx16vzvn3riRmh9eKP1vZzu0KrCh03dZ6yn+36JjnTk7TSp a7pfevtzeaLd4Fm2n5L5P23S3fP5NM8bGlDTNi8Q46W+ X-Google-Smtp-Source: ABdhPJxlWvqqpLeXqZWRVwzQr+CavReogpJ6CPgR6Xia58JHITTPMtK68aKsPd3yHJuwHjAnI1x7IeBwIwvAFc5Mows= X-Received: by 2002:a05:6000:186f:b0:20c:5f3d:44a4 with SMTP id d15-20020a056000186f00b0020c5f3d44a4mr9034412wri.152.1651997786170; Sun, 08 May 2022 01:16:26 -0700 (PDT) MIME-Version: 1.0 References: <5568db74d0acb198a3e8121ee75e3cfa02ea0c6f.camel@mad-scientist.net> <453082091.802975.1651922375216@mail.yahoo.com> <222e7c9b9ac74aa886c1501792e677a0dfa1f268.camel@mad-scientist.net> <27202f68e59e9a17aaa96d39659ce73005325cd7.camel@mad-scientist.net> In-Reply-To: From: Jonathan Wakely Date: Sun, 8 May 2022 09:16:13 +0100 Message-ID: Subject: Re: Help using the GDB C++ STL pretty-printers / xmethods To: Paul Smith Cc: gcc-help X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sun, 08 May 2022 08:16:29 -0000 On Sun, 8 May 2022, 09:13 Jonathan Wakely, wrote: > > > On Sun, 8 May 2022, 00:09 Paul Smith, wrote: > >> On Sat, 2022-05-07 at 20:51 +0100, Jonathan Wakely wrote: >> > On Sat, 7 May 2022 at 20:07, Paul Smith >> > wrote: >> > GCC's 'make install' should do everything needed. That installs >> > $prefix/lib64/libstdc++.so.6.0.30-gdb.py alongside the .so file, and >> > gdb auto-loads that when debugging a process linked to the >> > libstdc++.so.6.0.30 library. That python script imports the >> > register_libstdcxx_printers function and runs it. >> > >> > Maybe you're only linking statically to libstdc++.a? >> >> Ah. Yes I'm linking statically. >> >> > Hmm, that's reminiscent of >> > https://sourceware.org/bugzilla/show_bug.cgi?id=25234 >> >> I checked and when I first attach I do see: >> >> (gdb) show lang >> The current source language is "auto; currently c". >> >> and things don't work, then after I change to a C++ frame I see: >> >> (gdb) show lang >> The current source language is "auto; currently c++". >> >> and things work. >> >> I discovered that if I add: >> >> set language c++ >> >> to my init, that it all works properly. For my purposes this is a >> sufficient workaround. >> >> It's a bit strange (confusing) that the C++ pretty-printers work >> without having to do that, but the C++ xmethods do not. >> >> Also just a data point, my previous GDB (10.2) didn't require this: >> when I attach with that version, GDB chose the auto language as "c++" >> immediately. I suppose it's worth a bugzilla report. >> >> > All the logic to do that in Python is already present in the >> > printers, >> >> I figured so I'd hoped there was something here already. I get what >> you're saying of course. Maybe I'll find some time to dig into this... >> at some point... >> >> > > (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. >> > >> > The UniquePtrGetWorker Xmethod already does that. You should be able >> > to just do: >> > >> > py ptr = gdb.parse_and_eval('uniqptr.get()') >> >> xmethods don't help me (IIUC) because I'm in the middle of some Python >> function and the value I want to retrieve is in a Python variable, not >> in a GDB variable, so I can't easily access it with parse_and_eval(). >> >> For instance in my examples here I'd have a python method: >> >> def find_obj(val): >> if val['mgr']['initialized']: >> return val['mgr'] >> return val['otherMgr'] >> >> or whatever, but of course I can't do this because val['mgr'] is a >> std::unique_ptr and I don't know how to dig out the object it points >> to. The above doesn't need to work as-is: something like: >> >> def find_obj(val): >> mgr = StdUnique(val['mgr']).get() >> if mgr['initialized']: >> return mgr >> return val['otherMgr'] >> >> or whatever would be fine. >> > > > gdb.set_convenience_variable('mgr', val['mgr']) > init = gdb.parse_and_eval('$mgr->initialized') > > This will use the xmethod to evaluate the expression. > And then: if init: return gdb.parse_and_eval('*$mgr')