From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by sourceware.org (Postfix) with ESMTPS id 539BD383F953 for ; Mon, 23 May 2022 17:06:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 539BD383F953 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-wr1-f54.google.com with SMTP id e28so21682822wra.10 for ; Mon, 23 May 2022 10:06:25 -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=vYWYHxYbFNBEXTfvwaV0aVBHCw9SmY1lwgx0PLjumAA=; b=BG4bY4XtNVtrq3FJp3RLCkUl5hgbiGt81Tfo2A+o++ZkKiJV1pJn3+FP2qXehbwkWX VbbXnPGiHALvpWjAR4T9/eU2r2Nno/hr4CnsKm5kkSJLUnQFNnX3pA5igZWGiu0q8kf3 EScEpISLeWFNATQejWbfXSKQEe+/rOtp+BVAWSUEpZOkvvBlVtM8lf381pwEKmWOEbu0 5gvxeX7OImUQ9GpKRhJWPhZPLN9cULxs/wDsGTPHXomhLWMRBpUYEyQFf7UGeh/BSENu jaq8AB8Jfct2YfPTQfLV+kVmCinG1r2kzlLOb+0NHXKZSXVgsYxIsEDqH67IvXySHiK8 PN+A== X-Gm-Message-State: AOAM532K/OwAufsYSfEIpIxXLgignIN5KMQPpjedUdql5s0ti0LiyYVA HAiof2W4bDudDWzFNeY2/Yeb7zdm5as= X-Google-Smtp-Source: ABdhPJycGE55WLRBb67eVa3hZ1gP9hwghiZPBBDy2X5/ZIbeNkKt/HTzNYRD/httI/Ea3kOD/OVIQA== X-Received: by 2002:a05:6000:1548:b0:20f:c4bb:defd with SMTP id 8-20020a056000154800b0020fc4bbdefdmr10763165wry.210.1653325584298; Mon, 23 May 2022 10:06:24 -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 x17-20020adfae11000000b0020fe7f7129fsm2102793wrc.100.2022.05.23.10.06.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 May 2022 10:06:23 -0700 (PDT) Message-ID: <869dd733-daae-ad7d-b53e-435d85d10406@palves.net> Date: Mon, 23 May 2022 18:06:22 +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> From: Pedro Alves In-Reply-To: <835ym0d9v8.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: Mon, 23 May 2022 17:06:26 -0000 On 2022-05-20 06:57, Eli Zaretskii wrote: >> From: Pedro Alves >> Date: Thu, 19 May 2022 22:55:50 +0100 >> >> we get: >> >> (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. The "What" column is showing different things for the breakpoint and its locations. I've explained in a lot of detail why I think we want this in the commit log of patch #1, and now in the reply to your review of patch #1 too. > >> Patch #2 introduces an "info breakpoints -hide-locations" option. >> With that, you get just the breakpoint header rows, showing the >> canonical location spec originally used to set the breakpoint, but not >> what the spec expanded to: >> >> (top-gdb) i b -h >> 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. I.e., I want to still see all information about each of the breakpoints, just not its resolved locations. I only made -hide-locations skip the "Address" column because it would always be empty otherwise. For example, here I set a tbreak, and I have a silent breakpoint: (top-gdb) info breakpoints -h Num Type Disp Enb What 1 breakpoint keep y internal_error 2 breakpoint keep y info_command silent return 3 breakpoint keep y main breakpoint already hit 1 time 4 breakpoint del y get_selected_frame stop only if debug_infrun > 0 So, a more concise display may be interesting, but I'd like to think of it as a separate feature.