From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by sourceware.org (Postfix) with ESMTPS id 027F1383A33A for ; Tue, 24 May 2022 13:45:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 027F1383A33A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f44.google.com with SMTP id h19-20020a05600c351300b003975cedb52bso971131wmq.1 for ; Tue, 24 May 2022 06:45:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=jC6JQL6FjxdpTzFPVhu513nLPdDUaAtkCH98rJKG0tM=; b=zN8qS7yODLm4eGRTjVuHHhbnhzd6NsQtepupWzPyFe3gYtdMZujm/bLRTSBwLYzC2v 31Fpynq3VEs+40rG4/95MBw1r7OjeBeSMjLLSMJqGmUmcrrzcJL1wdm0FDPVcUZsBO1L y1SVUyKLVn1WyJ4TKMrO46jWShzfp1BocXO7hDdLj1WsqSbuBNSgdMBIuSaXrSrIKZKg og8bKqHS+K0EwQF4VmrXRXi7dE2ORdA9AkUYnMoO37clSZFrHW/um8I5oziNky7j7k2S Y27Smhuqt5VeCDa7qCp8fJyR81RRM1L4hWM2hpmfxM6+sfJun1EQc2WZSGlxbeMVaBh9 E4eg== X-Gm-Message-State: AOAM532Pkuqb+kpfbiMntQjwFb3m/SxnKAzP3f4Z6edY4RUaYLW6Z5gs /9KX1f0DlB+OrRn8WbAGfno= X-Google-Smtp-Source: ABdhPJydjWYYiOcvnZ8A/DLNuNRH+JplylAaaq29wqeVuM3l5rc4ao7e3Qac2bT6oQLUV1q6CQcA7g== X-Received: by 2002:a05:600c:1504:b0:397:4d98:8b85 with SMTP id b4-20020a05600c150400b003974d988b85mr3908709wmg.39.1653399944640; Tue, 24 May 2022 06:45:44 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id v7-20020a056000144700b0020ffb018d21sm400314wrx.110.2022.05.24.06.45.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 May 2022 06:45:43 -0700 (PDT) Message-ID: <724f9c18-2a1f-de3e-b4fc-6c680a20194c@palves.net> Date: Tue, 24 May 2022 14:45:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 0/2] info breakpoints improvements Content-Language: en-US To: Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20220519215552.3254012-1-pedro@palves.net> <835ym0d9v8.fsf@gnu.org> <869dd733-daae-ad7d-b53e-435d85d10406@palves.net> <83h75f5ayf.fsf@gnu.org> From: Pedro Alves In-Reply-To: <83h75f5ayf.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 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:45:51 -0000 On 2022-05-24 14:14, Eli Zaretskii wrote: >> 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. > Well, with that view, this is very hard to discuss. The example quoted at the top shows that breakpoints 1 through 3 all have the same breakpoint location in internal_error at src/gdb/common/errors.c:54 , yet, they were all specified differently. There is no way to distinguish them in the CLI today. "internal_error" alone is not a source location, it's just a way to tell GDB to find the locations where that function exists. It's just a function name. The source location is the address, filename and line number tuple. >> The "What" column is showing different things for the breakpoint >> and its locations. > > Different, but in many cases quite similar, with many common parts. Sure. But not always, and thus I find it important to show the missing info, so we can tell which is which. >> 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. I accept your feedback, and concede that it may be interesting to have a mode that prints a more concise display. But I find it a different feature. Nothing prevents you or someone else from adding some "info breakpoints -concise" option. It would be up to debate what exactly does "concise" show, e.g., whether that would mean we print the breakpoint's commands too, for example. For me, I would like a flag that only suppresses the locations and nothing else, and that is very easy to specify (there's no scope for divergence on what "hiding locations" means) so that's what I am proposing.