Re: [PATCH v1 2/4] gdb/python: eval_python_command returns both exit code and result

[Matthieu Longo <matthieu.longo@arm.com>]

On 17/04/2026 18:22, Tom Tromey wrote:
>>>>>> Matthieu Longo <matthieu.longo@arm.com> writes:
> 
>> A previous commit [1] centralized the Python code evaluation in the
>> helper function eval_python_command(). However, a missed case in
>> varobj_set_visualizer() requires both the exit code and the result
>> of the evaluation.
> 
>> This patch updates eval_python_command() to return both values and
>> adjusts existing callers accordingly. It also replaces the use of
>> PyRun_String() in varobj_set_visualizer() with a call to
>> eval_python_command().
> 
> Could we have it just return null on failure?
> And always return a gdbpy_ref<>?
> 

Yes, we can do that. I hadn't noticed that NULL was returned in case of an error occurred during the 
evaluation. To be honest, the Python doc is not super-clear about what is supposed to be returned.

>> --- a/gdb/python/python.c
>> +++ b/gdb/python/python.c
>> @@ -299,42 +299,40 @@ gdbpy_check_quit_flag (const struct extension_language_defn *extlang)
>>      NULL means that this is evaluating a string, not the contents of a
>>      file.  */
>   
>> -int
>> +std::pair<int, gdbpy_ref<>>
>>   eval_python_command (const char *command, int start_symbol,
>>   		     const char *filename)
> 
> Either way I think the comment needs an update to describe the return
> result.
> 

Fixed in the next revision.

>> +  if (mainmod == nullptr)
>> +    return std::make_pair(-1, nullptr);
>   
> Space before parens throughout, though of course this is moot if
> returning gdbpy_ref<>.

Moot now.

> 
> Tom

Matthieu