From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KAQqJ45jlGBwLwAAWB0awg (envelope-from ) for ; Thu, 06 May 2021 17:45:50 -0400 Received: by simark.ca (Postfix, from userid 112) id 9ECB51F11C; Thu, 6 May 2021 17:45:50 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 031201E783 for ; Thu, 6 May 2021 17:45:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B04933AAB4A7; Thu, 6 May 2021 21:45:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B04933AAB4A7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620337549; bh=JHt68jwy2b//kYBCSq91IVq4E11x2mPTHNcXep3YZUw=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ycmjqU9XhWE8N2SZ91hNMf7g1wKTDMERJf4IlVssgcHR0Ak7CtM9jfUix4Xjp6UNl gmfxG5OgpxQRaj79qvtU3dmSl/a3/6V7hpzbfPanwXDGnEM5zXF/1wczUAIoS/NSdq DfNES0RJ48WZhGwfN9UBawSdTf+vC5oLvaJwffeQ= Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 536A93AAB4A8 for ; Thu, 6 May 2021 21:45:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 536A93AAB4A8 Received: by mail-pl1-x62e.google.com with SMTP id b21so4137313plz.0 for ; Thu, 06 May 2021 14:45:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JHt68jwy2b//kYBCSq91IVq4E11x2mPTHNcXep3YZUw=; b=gXKzsoaxbo4c4PzTclq4GrFvi/ZrGKOKQ8EUjlGTvErr+UQ3Iu32wnR0EnM68qNkaL EuTHNmxS6dWn2/Cyk5Go/vmzPWlL5d4wdH7+l7KW4/L20gn+EDkvSztkV1zJXwsxq2wU 2bX3GBI6CNWlXT3VU3GPdRVDWrQCtoQXvByqiAcVSDlCHYWUFXomO3iY71gWJqleo2Bi K97d/TjI4PKj7mtE9CfuO3il1d+Du8wJqSf/IcSDXRxTlv7Ozxs0gtZrzrEZGPSDJapI BvN9CVyEZIEaZ0RQKunPQbDIaIu9BpRBYUCM2K4yc4lEcfcdDPctXOJdeWc/YExI7Dq0 Y7Kw== X-Gm-Message-State: AOAM531jn56rklf0ssD6czW+G0ANYoY7SPue8VOyt23MG4Nsno9BDdUq lEvZ0MrLaL6DL7pun2hwTJlYCUhTxJCHAwfX6ZtF/Y0G X-Google-Smtp-Source: ABdhPJyFNBv+/nsyIzD+E6dm5qlX2nzxLRqHcPG0m9lmaAIGdbAMcMEvCqm6clQJSX+GmcNRchBCt/YM0E9V/Iij5JE= X-Received: by 2002:a17:90a:c201:: with SMTP id e1mr6776136pjt.222.1620337545515; Thu, 06 May 2021 14:45:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 6 May 2021 14:45:34 -0700 Message-ID: Subject: Re: debugging coredumps with the help of libraries (for example to pretty-print) To: Simon Sobisch Content-Type: text/plain; charset="UTF-8" X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: David Blaikie via Gdb Reply-To: David Blaikie Cc: gdb@sourceware.org Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" Not sure about other answers/details, but generally it's encouraged to do the latter - pretty printers that do not invoke any code in the process, both for debugging cores, but also in general to avoid any risk that the pretty printer might taint the process under test by executing code that could risk changing the state of the process, etc. On Thu, May 6, 2021 at 1:48 PM Simon Sobisch via Gdb wrote: > > I currently think there is no way, but before "giving up" I've wanted to > double-check, maybe I've missed something. > > To pretty-print some data types it seems quite feasible to use whatever > library handles the typedefs normally and use its string functions to > get the developer-view of the data and let gdb output that. > And this actually works quite well, just `gdb.execute("call > libfunc(...)") and you're done. > > But when I now create a core-dump (gcore dumpfile) and then start gdb > with to debug that I see the full state and local variables - but none > of those pretty printers work, resulting in "You can't do that without a > process to debug." messages. > > Is it possible to let GDB itself load the libraries and pass resolve the > string values that way (or somehow start a "new" process along with the > coredump only for letting it print the values from the coredump data)? > > If not then it is either "disable the pretty printing when a coredump is > processed" [what is the best check for that in a python extension btw?] > or try to re-implement the string function completely in python. > > Note: I actually can also change the library in question if that helps, > but I'd (also) be interested to know the answer of this question in general. > > Any hints welcome, > Simon Sobisch