Re: [PATCH][gdb/testsuite] Support .debug_aranges in dwarf assembly

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-08-27 9:35 a.m., Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Tom> +    #   arange [-c <comment>] [<segment selector>] <start> <length>
> 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