Re: [PATCH] Make gdb_caching_proc support namespaces

[Simon Marchi <simark@simark.ca>]

On 2025-09-15 19:57, Pedro Alves wrote:
> On 2025-09-15 22:54, Pedro Alves wrote:
>> I should have mentioned something here:
>>
>> On 2025-09-15 22:28, Pedro Alves wrote:
>>
>>> --- a/gdb/testsuite/lib/cache.exp
>>> +++ b/gdb/testsuite/lib/cache.exp
>>> @@ -24,26 +24,9 @@ proc ignore_pass { msg } {
>>>  
>>>  # Call proc real_name and return the result, while ignoring calls to pass.
>>>  proc gdb_do_cache_wrap {real_name args} {
>>> -    if { [info procs save_pass] != "" } {
>>> -	return [uplevel 2 $real_name]
>>> +    with_override pass ignore_pass {
>>> +	return [$real_name {*}$args]
>>>      }
>>
>> The previous code was using "uplevel 2" here.  But I'm struggling to see why that is the
>> right level.
>>
>> When gdb_do_cache_wrap is called via gdb_caching_proc => gdb_do_cache, that takes us to the scope of
>> the caller of the gdb_caching_proc, which off hand would seem right.
>>
>> However, when gdb_do_cache_wrap is called directly by gdb.testsuite/gdb-caching-proc-consistency.exp, it
>> takes us to ... the caller of test_proc?
>>
>> So I'm wondering, what could we possibly want to reference from a higher level in gdb_do_cache_wrap
>> that not having the uplevel in gdb_do_cache_wrap would get wrong?  A caching proc IMO shouldn't be doing
>> something like taking the name of a variable as argument instead of a value, as then the procedure wouldn't
>> be guaranteed to be idempotent?  So I dropped the uplevel, and found that that doesn't cause any
>> testsuite regression.  But maybe I'm missing something.  If I am, it'd be nice to add a testcase for it.
> 
> Trying to find a testcase for the above, I thought to try a gdb_caching_proc defined in a namespace,
> and have that proc access a namespace variable, in its own namespace.
> 
> That ran into the fact that gdb_caching_proc doesn't support namespaces today.  So I fixed that, with
> the patch below (on top of the previous one), which includes tests.  That still didn't require any
> uplevel in gdb_do_cache_wrap.
> 
> I don't have a current use for this, but I figure that eventually we will find a use, and since
> I wrote it...

I haven't looked at the code, but it fixes the problem for me.

Tested-By: Simon Marchi <simon.marchi@efficios.com>

Simon