From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6A9D23858C51 for ; Tue, 21 Jun 2022 16:12:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6A9D23858C51 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-593-cOIoom5YNEmdK--_cKaJDA-1; Tue, 21 Jun 2022 12:12:25 -0400 X-MC-Unique: cOIoom5YNEmdK--_cKaJDA-1 Received: by mail-wr1-f72.google.com with SMTP id ck13-20020a5d5e8d000000b0021b984d1565so624663wrb.10 for ; Tue, 21 Jun 2022 09:12: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:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=WjPeJc8mNSUDM51zBi54ohsgaoT5x+orSkJklTjlbt8=; b=4vqsVbRk9ne8zMgR3cwPFp6l7NT2uyQ8vkiLoyvGUBQlJ0L919umyeDY0g3RQLQi6s GUB5/CLVLracygucCaTFrGbF45pzaL1/yk8JjfJexEDZFpe5qb++i/LIIYCMFFwAjlLM DkkJVcKgOPNmTTqca88oXCzSpGR5biYzam6ySl5e+RpUCCqFJn1tVKvoTMtWBaHya+TH 8b8kHA2E8FFIazpMcytSgyBNO3Ekeja2rFeIIrNe6Kc9UaIJM5lmdBEYPfZsRta0VXov 1G30wLRp34rwhLvE/I5gTQsN3+cX6D1RvolMrX/WbEFc/Sv/kMZoXSVx2XMUo+/U77XS PFuQ== X-Gm-Message-State: AJIora/B/O45jP8f0Ae+50r3GhJQJUJBmHN3ajF5CXEGryGc+TDzIdnm B9ObjEimTT4mP5WwmPiZq07tp5cTboU6G88TBNTq7WwAOZMnVpQsrjfELizgOo4Gg40XYl44hUy CTSMgft7bANoxbeDYXA4sLQ== X-Received: by 2002:a05:6000:1a8b:b0:219:ad61:f4e3 with SMTP id f11-20020a0560001a8b00b00219ad61f4e3mr29925228wry.190.1655827944541; Tue, 21 Jun 2022 09:12:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v1mhPlgEA/U645IkPfSru5A/Xab8DmWeVN+kUPIqVk5WK1pNxnYcA/Vwb/6djpU3Yar7mo8w== X-Received: by 2002:a05:6000:1a8b:b0:219:ad61:f4e3 with SMTP id f11-20020a0560001a8b00b00219ad61f4e3mr29925198wry.190.1655827944285; Tue, 21 Jun 2022 09:12:24 -0700 (PDT) Received: from localhost ([213.31.44.107]) by smtp.gmail.com with ESMTPSA id n37-20020a05600c502500b0039c5cecf206sm19505450wmr.4.2022.06.21.09.12.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jun 2022 09:12:23 -0700 (PDT) From: Andrew Burgess To: Enze Li , gdb-patches@sourceware.org Cc: pedro@palves.net, enze.li@gmx.com Subject: Re: [PATCH 1/2] gdb/testsuite: move get_maint_bp_addr to gdb-utils.exp In-Reply-To: References: Date: Tue, 21 Jun 2022 17:12:21 +0100 Message-ID: <87a6a6c7x6.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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, 21 Jun 2022 16:12:29 -0000 Enze Li via Gdb-patches writes: > The get_maint_bp_addr procedure will be shared by other test suite, so > move it to gdb-utils.exp. > --- > gdb/testsuite/gdb.base/clear_non_user_bp.exp | 23 -------------------- > gdb/testsuite/lib/gdb-utils.exp | 23 ++++++++++++++++++++ > 2 files changed, 23 insertions(+), 23 deletions(-) > > diff --git a/gdb/testsuite/gdb.base/clear_non_user_bp.exp b/gdb/testsuite/gdb.base/clear_non_user_bp.exp > index 26d7a31fa47..399a3a0f0dc 100644 > --- a/gdb/testsuite/gdb.base/clear_non_user_bp.exp > +++ b/gdb/testsuite/gdb.base/clear_non_user_bp.exp > @@ -16,29 +16,6 @@ > # Regression test for PR gdb/7161. Test that GDB cannot delete non-user > # breakpoints with clear command. > > -# get_maint_bp_addr num > -# > -# Purpose: > -# Get address of the specified internal breakpoint when using command > -# "maint info breakpoints $num". > -# > -# Parameter: > -# The parameter "num" indicates the number of the internal breakpoint > -# to get. Note that this parameter must be a negative number. > -# E.g., -1 means that we're gonna get the first internal breakpoint. > -# > -# Return: > -# Internal breakpoint address. > -# > -proc get_maint_bp_addr { num } { > - gdb_test_multiple "maint info break $num" "find address of internal bp $num" { > - -re -wrap ".*(0x\[0-9a-f\]+).*" { > - return $expect_out(1,string) > - } > - } > - return "" > -} > - > # get_first_maint_bp_num > # > # Purpose: > diff --git a/gdb/testsuite/lib/gdb-utils.exp b/gdb/testsuite/lib/gdb-utils.exp > index ffdfb75557c..bf2863722ce 100644 > --- a/gdb/testsuite/lib/gdb-utils.exp > +++ b/gdb/testsuite/lib/gdb-utils.exp > @@ -72,3 +72,26 @@ proc style {str style} { > } > return "\033\\\[${style}m${str}\033\\\[m" > } > + > +# get_maint_bp_addr num > +# > +# Purpose: > +# Get address of the specified internal breakpoint when using command > +# "maint info breakpoints $num". > +# > +# Parameter: > +# The parameter "num" indicates the number of the internal breakpoint > +# to get. Note that this parameter must be a negative number. > +# E.g., -1 means that we're gonna get the first internal breakpoint. > +# > +# Return: > +# Internal breakpoint address. > +# > +proc get_maint_bp_addr { num } { > + gdb_test_multiple "maint info break $num" "find address of internal bp $num" { > + -re -wrap ".*(0x\[0-9a-f\]+).*" { > + return $expect_out(1,string) > + } > + } > + return "" > +} Before the get_maint_bp_addr name gets spread around too much, I think we should rename this. I'd propose maybe gdb_get_bp_addr. The comment should be reworked to remove the mention of negative values, as I believe this function will work just as well with positive values. I think the comment should also be expanded to indicate that (currently) this function will only take integer values for NUM, and will return the first address for a particular breakpoint, e.g. we can't say 'get_maint_bp_addr 1.2' to get the address of the second location of breakpoint #1. I don't think that we need to make the actual implementation of get_maint_bp_addr better right now, but if we give the function a good name, and explain the limitations in the comments, then, if we ever need to, we can improve the function later. Thanks, Andrew > -- > 2.36.1