From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6liSKymKn2AqNQAAWB0awg (envelope-from ) for ; Sat, 15 May 2021 04:45:29 -0400 Received: by simark.ca (Postfix, from userid 112) id A4F241F11C; Sat, 15 May 2021 04:45:29 -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 87E371E01F for ; Sat, 15 May 2021 04:45:28 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 003D23951883; Sat, 15 May 2021 08:45:28 +0000 (GMT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 3CDCB385E001 for ; Sat, 15 May 2021 08:45:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3CDCB385E001 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-wm1-x333.google.com with SMTP id b19-20020a05600c06d3b029014258a636e8so835205wmn.2 for ; Sat, 15 May 2021 01:45:24 -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=8zSb0TlcyVx7G3JV2Gq9UrhHeMLZksB5C93JVP8p7hI=; b=INWo7shuCvliuXdZD0euoXa6b/8IhCa63RKSc0xqf4x8MrpThjso1pbLuFsdBEyScd QVws8hFrULuyhKAAvsboDfpcyB15+TI75znw9G5HAP3V55LhqRuOXWnCd7Z8Z6ETg2le j9WHuk5r67qqG6JZeLA5n2YY227rmDUzLGNCWgguBOXsOnoPxNl5+LjGvYVcSEhHTB0B twKX9AvMBMFfJ4wqajHX/G0IqrWzvY355uqBJQVsWOtKxpPu/rCSg1Wqd0UZTe7p9ly6 p+vvDIsdc+NTGjtjSuqivKejsuludW1k+6wQh4g6ZnR3w+mm4RYdEm38v8B2hr/BXeNy UCSQ== 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=8zSb0TlcyVx7G3JV2Gq9UrhHeMLZksB5C93JVP8p7hI=; b=c6f72odRMyR1VrJUUJGkuqO8dxJE+nk9X3D3qTCdJty0ChaT+xehS/x5SC/10T7bLX v22VGLk2poX+v+iMzaMtFvm9Ob4FW6KKaQRVB9mB5mnH4l8tSAHtkM8ZBSYcCNEzQwRb +aJbw+q1LR8ntgH5XVEOjqOadRGIgol+BkuAtoqm7/3LUA/sVm/5O7soOwUbQxWDi6Ty Ph5naAkd7O5tDVLxuIp1+juL0yihySs/821qfYyzSpdmBJdsVczbLOtZ7aiEP+JB3WFX kxMpH/prrf8Y6JIexf1NpZs1IRD6doHpFp0af2psANN+kPNKIa+vR6NgayikygpN44AO ee9g== X-Gm-Message-State: AOAM532skbyeOJY5cvgfBJh4nlseaJM/mpTHg0JsA7wB/DcRM7ir8Jf8 45iC2UsBDIselHvvTweh+yjF4Q== X-Google-Smtp-Source: ABdhPJwr/lU5Jc/PWSIYwuQXZT/YeZ7WwlS4h0QXWXAOrgHAYcbidWP6n7hhSch6ieMRS8fHn2cxYQ== X-Received: by 2002:a1c:f705:: with SMTP id v5mr13510731wmh.69.1621068323248; Sat, 15 May 2021 01:45:23 -0700 (PDT) Received: from localhost (host109-151-46-70.range109-151.btcentralplus.com. [109.151.46.70]) by smtp.gmail.com with ESMTPSA id n123sm13731276wme.24.2021.05.15.01.45.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 May 2021 01:45:22 -0700 (PDT) Date: Sat, 15 May 2021 09:45:21 +0100 From: Andrew Burgess To: Simon Marchi Subject: Re: [PATCH 3/4] gdb: add new -group-by-binary flag to info sources command Message-ID: <20210515084521.GL3067949@embecosm.com> References: <760d52a0ea6ab8c2195d71feea794f0bec70a163.1619456691.git.andrew.burgess@embecosm.com> <5f7a72f3-a352-c107-4d10-3fadb7ecee38@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f7a72f3-a352-c107-4d10-3fadb7ecee38@polymtl.ca> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 09:42:53 up 11 days, 21:37, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" * Simon Marchi [2021-05-13 11:05:44 -0400]: > On 2021-04-26 1:07 p.m., Andrew Burgess wrote: > > Currently the 'info sources' command lists all of the known source > > files together, regardless of their source, e.g. here is a session > > debugging a test application that makes use of a shared library: > > > > (gdb) info sources > > Source files for which symbols have been read in: > > > > /tmp/info-sources/test.c, /usr/include/stdc-predef.h, > > /tmp/info-sources/header.h, /tmp/info-sources/helper.c > > > > Source files for which symbols will be read in on demand: > > > > (gdb) > > > > In this commit I add a new flag to the 'info sources' command, > > '-group-by-binary'. When this flag is provided the results are > > grouped by the binary file that uses that source file. Here's the > > same session using the new flag: > > > > (gdb) info sources -group-by-binary > > /tmp/info-sources/test.x: > > > > /tmp/info-sources/test.c, /usr/include/stdc-predef.h, > > /tmp/info-sources/header.h > > > > /lib64/ld-linux-x86-64.so.2: > > (Full debug information has not yet been read for this file.) > > > > system-supplied DSO at 0x7ffff7fcf000: > > (Full debug information has not yet been read for this file.) > > > > /tmp/info-sources/libhelper.so: > > > > /tmp/info-sources/helper.c, /usr/include/stdc-predef.h, > > /tmp/info-sources/header.h > > > > /lib64/libc.so.6: > > (Full debug information has not yet been read for this file.) > > > > (gdb) > > > > Notice that in the new output some source files are repeated, > > e.g. /tmp/info-sources/header.h, as multiple binaries use this source > > file. > > > > All of the existing regular expression based filtering that exists for > > 'info sources' still works with the new option. > > In my opinion the new output is just better, more structured. Do we > even need to hide it behind an option? Can we just... change it and > that's it? I'd lke if we didn't have to keep the extra complexity > unnecessarily. I'm not against changing the output, but I thought as a rule we didn't significantly change existing command behaviour unless we could show that the existing behaviour was wrong. I guess how do folk feel about changing this behaviour? Thanks, Andrew