gdb/mi: Fix printing of fortran strings in stack

  547ce8f00b4ef826bdc9bf9a74f119fe9768852e fixed an issue where dynamic
types were not being resolved correctly prior to printing a value. The
same issue was discovered when printing the value using MI-mode. Solved
by porting the fix to the MI mode code path.

GDB built with GCC 13.

No test suite regressions detected. Compilers: GCC 12.1.0, ACfL 22.1,
Intel 22.1; Platforms: x86_64, aarch64.

Co-Authored-By: Josh Cottingham <josh.cottingham@arm.com>

---
 gdb/mi/mi-cmd-stack.c                          |  3 +++
 gdb/testsuite/gdb.fortran/mixed-lang-stack.exp | 12 ++++++++++++
 2 files changed, 15 insertions(+)
  

Richard Bunt via Gdb-patches <gdb-patches@sourceware.org> writes:

> 547ce8f00b4ef826bdc9bf9a74f119fe9768852e fixed an issue where dynamic
> types were not being resolved correctly prior to printing a value. The
> same issue was discovered when printing the value using MI-mode. Solved
> by porting the fix to the MI mode code path.
>
> GDB built with GCC 13.
>
> No test suite regressions detected. Compilers: GCC 12.1.0, ACfL 22.1,
> Intel 22.1; Platforms: x86_64, aarch64.
>
> Co-Authored-By: Josh Cottingham <josh.cottingham@arm.com>

Thanks for fixing this.  Looks good to me.

Approved-By: Andrew Burgess <aburgess@redhat.com>

Thanks,
Andrew

>
> ---
>  gdb/mi/mi-cmd-stack.c                          |  3 +++
>  gdb/testsuite/gdb.fortran/mixed-lang-stack.exp | 12 ++++++++++++
>  2 files changed, 15 insertions(+)
>
> diff --git a/gdb/mi/mi-cmd-stack.c b/gdb/mi/mi-cmd-stack.c
> index 0172bf9814d..70762880c49 100644
> --- a/gdb/mi/mi-cmd-stack.c
> +++ b/gdb/mi/mi-cmd-stack.c
> @@ -590,6 +590,9 @@ list_args_or_locals (const frame_print_options &fp_opts,
>  
>    ui_out_emit_list list_emitter (uiout, name_of_result);
>  
> +  scoped_restore_selected_frame restore_selected_frame;
> +  select_frame (fi);
> +
>    while (block != 0)
>      {
>        for (struct symbol *sym : block_iterator_range (block))
> diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
> index 6ab3f8adeba..5fc36f7b95b 100644
> --- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
> +++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
> @@ -92,6 +92,18 @@ proc run_tests { lang } {
>  	    }
>  	}
>  
> +	# Check backtrace arguments in MI mode.
> +	set mi_a "\{name=\"a\",value=\"1\"\}"
> +	set mi_b "\{name=\"b\",value=\"2\"\}"
> +	set mi_c "\{name=\"c\",value=\"3\"\}"
> +	set mi_d "\{name=\"d\",value=\"\\(4,5\\)\"\}"
> +	set mi_e "\{name=\"e\",value=\"$e_arg\"\}"
> +	set mi_g "\{name=\"g\",value=\"\\( a = 1.5, b = 2.5 \\)\"\}"
> +	# Hidden argument name changes depending on compiler.
> +	set mi_hidden "\{name=\"\[^\r\n\]+\",value=\"6\"\}"
> +	gdb_test "interpreter-exec mi '-stack-list-arguments --no-frame-filters --all-values 7 7'" \
> +		 "\\^done,stack-args=\\\[frame=\{level=\"7\",args=\\\[$mi_a,$mi_b,$mi_c,$mi_d,$mi_e,$mi_g,$mi_hidden\\\]\}\\\]"
> +
>  	# Check the language for frame #0.
>  	gdb_test "info frame" "source language fortran\..*" \
>  	    "info frame in frame #0"
> -- 
> 2.32.0
  

>>>>> "Richard" == Richard Bunt via Gdb-patches <gdb-patches@sourceware.org> writes:

Richard> 547ce8f00b4ef826bdc9bf9a74f119fe9768852e fixed an issue where dynamic
Richard> types were not being resolved correctly prior to printing a value. The
Richard> same issue was discovered when printing the value using MI-mode. Solved
Richard> by porting the fix to the MI mode code path.

I wonder if this can be fixed more directly after
2fc3b8a4cb8439fc53975c4e70336d76e3ddc531 and its predecessors.
(Not that there's anything wrong with this patch.)

Tom
  

On 10/05/2023 15:52, Tom Tromey wrote:
>>>>>> "Richard" == Richard Bunt via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Richard> 547ce8f00b4ef826bdc9bf9a74f119fe9768852e fixed an issue where dynamic
> Richard> types were not being resolved correctly prior to printing a value. The
> Richard> same issue was discovered when printing the value using MI-mode. Solved
> Richard> by porting the fix to the MI mode code path.
> 

Hi Tom,

Thanks for pointing me in the direction of that patch set.

> I wonder if this can be fixed more directly after
> 2fc3b8a4cb8439fc53975c4e70336d76e3ddc531 and its predecessors.
> (Not that there's anything wrong with this patch.)
> 
> Tom

Even better than that, it fixes the issue I was seeing. I mistakenly 
thought I was sufficiently in a corner that I'd not need to retest for 
the failure after rebasing.

If it is OK, I'd like to propose the test case for upstream as I believe 
it covers a legitimate gap, even if there is no known bug here.

Many thanks,

Rich.
  

>>>>> "Richard" == Richard Bunt via Gdb-patches <gdb-patches@sourceware.org> writes:

>> I wonder if this can be fixed more directly after
>> 2fc3b8a4cb8439fc53975c4e70336d76e3ddc531 and its predecessors.
>> (Not that there's anything wrong with this patch.)
>> Tom

Richard> Even better than that, it fixes the issue I was seeing.

Nice.  I wonder if we can remove the old fix then.

Richard> If it is OK, I'd like to propose the test case for upstream as I
Richard> believe it covers a legitimate gap, even if there is no known bug
Richard> here.

Yes, that would be great.  Thank you.

Tom
  

On 12/05/2023 19:38, Tom Tromey wrote:
>>>>>> "Richard" == Richard Bunt via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
>>> I wonder if this can be fixed more directly after
>>> 2fc3b8a4cb8439fc53975c4e70336d76e3ddc531 and its predecessors.
>>> (Not that there's anything wrong with this patch.)
>>> Tom
> 
> Richard> Even better than that, it fixes the issue I was seeing.
> 
> Nice.  I wonder if we can remove the old fix then.

I have confirmed that the fix applied to the cli-mode code path can be
removed.

I'll prepare a v2.

> 
> Richard> If it is OK, I'd like to propose the test case for upstream as I
> Richard> believe it covers a legitimate gap, even if there is no known bug
> Richard> here.
> 
> Yes, that would be great.  Thank you.
> 
> Tom

Thanks,

Rich.