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 C554E383A33A for ; Tue, 24 May 2022 13:15:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C554E383A33A Received: from fencepost.gnu.org ([2001:470:142:3::e]:36568) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntUNL-0003OD-RF; Tue, 24 May 2022 09:15:03 -0400 Received: from [87.69.77.57] (port=4538 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntUNI-0004ty-L3; Tue, 24 May 2022 09:15:01 -0400 Date: Tue, 24 May 2022 16:14:48 +0300 Message-Id: <83h75f5ayf.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <869dd733-daae-ad7d-b53e-435d85d10406@palves.net> (message from Pedro Alves on Mon, 23 May 2022 18:06:22 +0100) Subject: Re: [PATCH 0/2] info breakpoints improvements References: <20220519215552.3254012-1-pedro@palves.net> <835ym0d9v8.fsf@gnu.org> <869dd733-daae-ad7d-b53e-435d85d10406@palves.net> X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 24 May 2022 13:15:06 -0000 > Date: Mon, 23 May 2022 18:06:22 +0100 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > > >> (top-gdb) info breakpoints > >> Num Type Disp Enb Address What > >> 1 breakpoint keep y internal_error > >> 1.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 > >> 2 breakpoint keep y -qualified internal_error > >> 2.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 > >> 3 breakpoint keep y errors.c:54 > >> 3.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 > >> 3.2 y 0x00007ffff6d50410 in PyErr_SetObject at /usr/src/debug/python2-2.7.15-4.fc27.x86_64/Python/errors.c:54 > >> 4 breakpoint keep y gdb.c:27 > >> 4.1 y 0x000055555564107b in main(int, char**) at src/gdb/gdb.c:28 > >> (top-gdb) > > > > I must confess that the new display is much more cluttered, and > > includes redundant information, so it's harder to read. It also makes > > the important stuff harder to find. Why exactly is this deemed as > > improvement, and in particular, why would we want this behavior as the > > default? (I won't mind to have this as opt-in behavior, if someone > > finds this useful in some situations.) > > None of the information is actually redundant. The "Enb" column shows > a different "y", as you can disable a whole breakpoint, or its locations > independently. In the "usual" case, such as the one below: > >> 4 breakpoint keep y gdb.c:127 > >> 4.1 y 0x000055555564107b in main(int, char**) at src/gdb/gdb.c:127 one of the two "y"s is redundant, as well as one of the two "gdb.c:127"s. And in this case: >> 1 breakpoint keep y internal_error >> 1.1 y 0x00000000005755a5 in internal_error(char const*, int, char const*, ...) at src/gdb/common/errors.c:54 the "internal_error" part of the "header row" is also redundant. > The "What" column is showing different things for the breakpoint > and its locations. Different, but in many cases quite similar, with many common parts. > >> Num Type Disp Enb What > >> 1 breakpoint keep y internal_error > >> 2 breakpoint keep y -qualified internal_error > >> 3 breakpoint keep y errors.c:54 > > > > If we want a concise display that only shows the important parts, I'd > > lose the "Disp" column. > > I'm not sure how you're determining "important". That'd make it impossible to > distinguish a "break" from a "tbreak". I'm only after hiding the breakpoint locations. IME, the "tbreak" vs "break" difference is much less important than the rest. > So, a more concise display may be interesting, but I'd like to think of it as > a separate feature. It's okay to disagree about user perspectives on what a "concise" display should and should not have. I thought that providing the perspective of one (heavy) user of GDB on this will help make the discussion more objective and balanced. Apologies if that is not useful.