From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id B4D2D398B140 for ; Thu, 18 Jun 2020 10:57:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B4D2D398B140 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-208-PgoMrMCCPMqXgI3awRfiag-1; Thu, 18 Jun 2020 06:57:01 -0400 X-MC-Unique: PgoMrMCCPMqXgI3awRfiag-1 Received: by mail-wm1-f71.google.com with SMTP id k185so1655343wme.8 for ; Thu, 18 Jun 2020 03:57:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7GWwxL1N8WKnCC/Lkon/5fUdN+nx2ywE/DhMpBrbdPo=; b=Cw3XrvbXzz9FGlt9i4Q4nc/hcnNrpqTDX8wKizZjeA3h05g9PwHa8fwYGl5zhiVh4d bOlcbBiu5cySMXEaY56BfKmlt5AEFhZ/rMvSmVmkLXOUqqjrpq842uTT0StUGMLH8avv wDpH41bDuDgmqdeKec30f8Rw9gB9+Z5/Cm5pz4Hd+5vK+br150Kot9Z5R64hCRPp/N2i UoDirFJdyRDrkbG6p+qIxkOVLOEs0B8rx+XdAoeLXNhs3mGb8XUlFA8PsdfXaOXyKblC GsxofYJhLV5HGGxBVU72NoSGzsIGH/VIgu7yuklA2FTIOMihhZY7RA4HXWuuoFvKYnlu 3ewA== X-Gm-Message-State: AOAM531N69xLngFIIR5YbGwvCK/zyKdW+o9fdbINOR+eh73e6iibtj7Q H5zPpaxOx41pmdXfnhuHmtYLg4uOn0w/ULS1mbcDP741Qd2WIKLLcMzNII8TIWVcTWVg5KUHTRD uOkCZfYH5s+dV/ZSFHe9dqg== X-Received: by 2002:a1c:2e58:: with SMTP id u85mr3335741wmu.123.1592477820259; Thu, 18 Jun 2020 03:57:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWs5iblOsuh87AvO8fKL9v1zs30Fg6+Wh2LyCrEYenuyXevRWgX0NIOrT45oP08EWb+QROvw== X-Received: by 2002:a1c:2e58:: with SMTP id u85mr3335728wmu.123.1592477820028; Thu, 18 Jun 2020 03:57:00 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id f16sm3167700wmh.27.2020.06.18.03.56.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jun 2020 03:56:59 -0700 (PDT) Subject: Re: [PATCH][gdb/testsuite] Move code from gdb_init to default_gdb_init To: Tom de Vries , gdb-patches@sourceware.org References: <20200611143522.GA19667@delia> <7d7ce523-b58c-a77d-15be-8091feb6389a@redhat.com> <18e36963-4f04-f871-33fb-89a5d1683bbd@suse.de> <31b0b6f2-4930-f339-0245-3a328d0d2548@redhat.com> <80251b07-73db-1ca0-7ab6-67285cb6b1d7@suse.de> <605f6d30-4e18-cebc-517c-5a070e477823@redhat.com> <2dd9aa3e-3dcf-6fb1-bcc8-89312f107d11@suse.de> From: Pedro Alves Message-ID: <3881fbfb-a6d4-847d-6676-617daf173e14@redhat.com> Date: Thu, 18 Jun 2020 11:56:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2dd9aa3e-3dcf-6fb1-bcc8-89312f107d11@suse.de> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 18 Jun 2020 10:57:04 -0000 On 6/18/20 11:16 AM, Tom de Vries wrote: > [ was: Re: [PATCH][gdb/testsuite] Don't abort testrun for invalid > command in test-case ] > On 6/17/20 4:19 PM, Pedro Alves wrote: >> On 6/17/20 3:14 PM, Tom de Vries wrote: >>> On 6/16/20 2:47 PM, Pedro Alves wrote: >>>> On 6/11/20 11:55 PM, Tom de Vries wrote: >>>> >>>>> Hmm, what is the distinction between gdb_init and default_gdb_init? >>>>> >>>>> All the other uses in gdb.exp of pattern foo/default_foo have an >>>>> implementation: >>>>> ... >>>>> proc foo {} { >>>>> [default_foo] >>>>> } >>>>> ... >>>>> but gdb_init is much more than that. Why is that different? >>>>> >>>> >>>> I don't know. I guess it shouldn't. I guess people (including me) added to >>>> gdb_init over time without realizing they were breaking the pattern. Maybe nobody >>>> notices it because whatever is overriding gdb_init renames the original one and >>>> then calls it. >>> >>> Hmm, thanks for the explanation. I feel we need to improve this >>> situation somehow, but I'm not sure yet how. >> >> Move stuff in gdb_init to default_gdb_init, and add a comment to these >> functions to not add stuff in there? That seems like the obvious. >> I'm not sure why we have that pattern in the first place though, given >> that you can rename/override functions in tcl anyhow. This all predates me. > > How about this patch then? LGTM. (Comments should spell "GDB" instead of "Gdb" though.) Thanks, Pedro Alves