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

[Tom de Vries <tdevries@suse.de>]

On 8/29/21 9:54 PM, Simon Marchi wrote:
>> OK, I've integrated the subst bit (and made it conditional, that was
>> still missing).  Also added the subst part for the default arguments,
>> and added a proper log message.  Any further comments?
> 
> LGTM.
> 
>> [ FWIW, a bit of bike-shedding.  I could imagine a pattern where you
>> pair a proc <name> and <name>_ like this:
>> ...
>>   proc arange_ { options start len } {
>>     ...
>>   }
>>   proc arange { start len } {
>>     arange_ {} start len
>>   }
>> ...
>> to be able to do:
>> ...
>>   arange $start $len
>> ...
>> and:
>> ...
>>   arange_ { comment "bla" } $start $len
>> ...
>> which would be slightly less annoying that having to specify empty
>> options. ]
> 
> I don't mind either way.  Even nicer would be to allow both:
> 
>   arange $start $len
>   arange { comment "bla" } $start $len
> 
> But that would probably require going back to using args,

Yes, actually that is my much preferred option, and roughly what I
started out with, but apparently it's not good tcl style.

> which breaks
> the purpose of what you're doing here.
> 
> Just to understand how we can do this in a systematic and predictable
> way, would you do it just for "arange" or would you do it for all procs
> of this style, like "cu"?

I'd do it for all such procs.

> In some cases (like cu), the case of having
> options is more common than the case of not having options.  So would
> you still have "cu" without options and "cu_" with options?

Yes, cu_ or cu_1 or cu_o (where o stands for with options) or some such.

I think this should either be done everywhere (well, in lib/dwarf.exp at
least) or not at all.  I suspect it's one of those tricks that is easy
to pick up if you see it everywhere, but if it's used in just one
location it's easy to overlook or misunderstand.

Thanks,
- Tom