From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 484D23858C60 for ; Fri, 27 Aug 2021 15:09:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 484D23858C60 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 17RF9mSf024668 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Aug 2021 11:09:53 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 17RF9mSf024668 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 6923F1E813; Fri, 27 Aug 2021 11:09:48 -0400 (EDT) Subject: Re: [PATCH][gdb/testsuite] Support .debug_aranges in dwarf assembly To: Tom Tromey , Tom de Vries via Gdb-patches References: <20210826115625.GA22715@delia> <87eeafovsa.fsf@tromey.com> From: Simon Marchi Message-ID: <40b7d95e-cc02-38c7-5406-0fc83a2a1b28@polymtl.ca> Date: Fri, 27 Aug 2021 11:09:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <87eeafovsa.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 27 Aug 2021 15:09:48 +0000 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 27 Aug 2021 15:10:04 -0000 On 2021-08-27 9:35 a.m., Tom Tromey wrote: >>>>>> "Tom" == Tom de Vries via Gdb-patches writes: > > Tom> + # arange [-c ] [] > Tom> + # -- adds an address range. > > I wonder if there's a way to make this more tcl-ish, say by rearranging > the order of arguments so that things can be defaulted. I think the > "args"-parsing style should normally be a last resort. I personally don't like this style proc arange { arange_start arange_length {comment ""} {seg_sel ""} } ... because if you want to specify the last parameter, you need to give all the other optional ones before. I also agree that just having: proc arange { args } is not great, since we have to do the argument parsing by hand, and it's a bit opaque what the proc accepts. Could we consistently use the "options" pattern, such as the one used by aranges and cu? proc arange { options arange_start arange_length } The callers would look like: arange {} $start $length arange { comment $comment seg_sel $seg_sel } $start $length I think that's a good compromise. I could re-do the rnglists procs this way, if you'd like. > Tom> + proc arange { args } { > > This is nested in 'aranges', but that's weird style in Tcl. > It redefines the proc every time 'aranges' is invoked. > I think it's better to just namespace scope this. But doing it this way makes it so that you can only invoke arange when you are in aranges' body, isn't that useful? I guess the downside to redefining the proc everytime is performance, but that's really not a concern here (it runs quickly enough). Simon