[Bug symtab/26390] New: gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[Bug symtab/26390] New: gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

            Bug ID: 26390
           Summary: gdb.fortran/mixed-lang-stack.exp: error reading
                    variable in backtrace
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ I'm using gcc-8 for this PR, the test-case seems to have been implemented
with gcc-8 and later abi in mind, see PR26362 comment 22.  FWIW, same behaviour
with gcc-11. ]

While looking into PR26362 I noticed this in the backtrace on a successful test
run on x86_64:
...
#7  0x000000000040114f in mixed_func_1b (a=1, b=2, c=3, d=(4,5), e=<error
reading variable: value requires 140737488341744 bytes, which is more than
max-value-size>, g=..., _e=6) at mixed-lang-stack.f90:87^M
...

Grepping for it, it reproduces with all 4 language setttings:
...
$ grep e= gdb.log | sed 's/.* e=/e=/;s/g=.*//'
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e=..., 
e=..., 
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e=..., 
e=..., 
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e=..., 
e=..., 
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e=..., 
e=..., 
...

The e='...' are due to printing of e when it's the current frame (resulting
from commands "up/down" or "info frame"), and with this:
...
diff --git a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
b/gdb/testsuite/gdb.fortran/mix
ed-lang-stack.exp
index 793318626d..4047b548f9 100644
--- a/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
+++ b/gdb/testsuite/gdb.fortran/mixed-lang-stack.exp
@@ -50,6 +50,7 @@ proc run_tests { lang } {

        gdb_breakpoint "breakpt"
        gdb_continue_to_breakpoint "breakpt"
+       gdb_test_no_output "set print frame-arguments all"

        if { $lang == "c" || $lang == "c++" } {
            gdb_test "set language c" \
...
we have instead:
...
$ grep e= gdb.log | sed 's/.* e=/e=/;s/g=.*//'
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e='abcdef', 
e='abcdef', 
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e='abcdef', 
e='abcdef', 
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e="abcdef", 
e="abcdef", 
e=<error reading variable: value requires 140737488341744 bytes, which is more
than max-value-size>, 
e="abcdef", 
e="abcdef", 
...

So, this seems to be backtrace-specific.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
In the dwarf info, we have:
...
 <1><11f0>: Abbrev Number: 14 (DW_TAG_subprogram)
    <11f1>   DW_AT_name        : mixed_func_1b
    <11f7>   DW_AT_linkage_name: mixed_func_1b_
 <1><1162>: Abbrev Number: 10 (DW_TAG_base_type)
    <1163>   DW_AT_byte_size   : 8
    <1164>   DW_AT_encoding    : 5      (signed)
    <1165>   DW_AT_name        : integer(kind=8)
 <1><1169>: Abbrev Number: 7 (DW_TAG_const_type)
    <116a>   DW_AT_type        : <0x1162>
 <2><1250>: Abbrev Number: 9 (DW_TAG_formal_parameter)
    <1251>   DW_AT_name        : e
    <1255>   DW_AT_type        : <0x142c>
    <1259>   DW_AT_location    : 4 byte block: 91 98 7f 6       (DW_OP_fbreg:
-104; DW_OP_deref)
 <2><126c>: Abbrev Number: 19 (DW_TAG_formal_parameter)
    <126d>   DW_AT_name        : _e
    <1270>   DW_AT_type        : <0x1169>
    <1274>   DW_AT_artificial  : 1
    <1274>   DW_AT_location    : 2 byte block: 91 0     (DW_OP_fbreg: 0)
 <1><142c>: Abbrev Number: 27 (DW_TAG_string_type)
    <142d>   DW_AT_string_length: 5 byte block: 99 4d 2 0 0     (DW_OP_call4:
<0x126c>)
 <2><1437>: Abbrev Number: 28 (DW_TAG_subrange_type)
    <1438>   DW_AT_type        : <0x1162>
    <143c>   DW_AT_upper_bound : <0x126c>
...

It seems at least interesting that the string type at 0x142c has two ways to
get to the length: via DW_AT_string_length and via DW_AT_upper_bound.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
>  <1><142c>: Abbrev Number: 27 (DW_TAG_string_type)
>     <142d>   DW_AT_string_length: 5 byte block: 99 4d 2 0 0    
> (DW_OP_call4: <0x126c>)
>  <2><1437>: Abbrev Number: 28 (DW_TAG_subrange_type)
>     <1438>   DW_AT_type        : <0x1162>
>     <143c>   DW_AT_upper_bound : <0x126c>
> ...
> 
> It seems at least interesting that the string type at 0x142c has two ways to
> get to the length: via DW_AT_string_length and via DW_AT_upper_bound.

Hmm, AFAICT, read_tag_string_type ignores the subrange type, and creates it's
own based on DW_AT_string_length.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
I tried to use recursive_dump_type to print the type, but ran into an assert,
because recursive_dump_type tries to print the high bound as PROP_CONST, while
it's a PROP_LOCEXPR.  Tentative patch:
...
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index da1c58c65c..d3f460779a 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -4856,6 +4856,27 @@ print_gnat_stuff (struct type *type, int spaces)

 static struct obstack dont_print_type_obstack;

+static void
+dump_dynamic_prop (dynamic_prop &prop)
+{
+  switch (prop.kind ())
+    {
+    case PROP_CONST:
+      printfi_filtered (0, "%s", plongest (prop.const_val ()));
+      break;
+    case PROP_UNDEFINED:
+      printfi_filtered (0, "(undefined)");
+      break;
+    case PROP_LOCEXPR:
+    case PROP_LOCLIST:
+      printfi_filtered (0, "(dynamic)");
+      break;
+    default:
+      gdb_assert (false);
+      break;
+    }
+}
+
 void
 recursive_dump_type (struct type *type, int spaces)
 {
@@ -5115,13 +5136,11 @@ recursive_dump_type (struct type *type, int spaces)
     }
   if (type->code () == TYPE_CODE_RANGE)
     {
-      printfi_filtered (spaces, "low %s%s  high %s%s\n",
-                       plongest (type->bounds ()->low.const_val ()),
-                       (type->bounds ()->low.kind () == PROP_UNDEFINED
-                        ? " (undefined)" : ""),
-                       plongest (type->bounds ()->high.const_val ()),
-                       (type->bounds ()->high.kind () == PROP_UNDEFINED
-                        ? " (undefined)" : ""));
+      printfi_filtered (spaces, "low ");
+      dump_dynamic_prop (type->bounds ()->low);
+      printfi_filtered (0, "  high ");
+      dump_dynamic_prop (type->bounds ()->high);
+      printfi_filtered (0, "\n");
     }

   switch (TYPE_SPECIFIC_FIELD (type))
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
At this point:
...
(gdb) bt
#0  dwarf2_evaluate_property (prop=0x220ddf0, frame=0,
addr_stack=0x7fffffffc9b0, 
    value=0x7fffffffc820, push_initial_value=false)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/loc.c:2584
#1  0x00000000006bfa79 in resolve_dynamic_range (dyn_range_type=0x220dd60, 
    addr_stack=0x7fffffffc9b0) at
/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:2099
#2  0x00000000006bfd25 in resolve_dynamic_array_or_string (type=0x2220f10, 
    addr_stack=0x7fffffffc9b0) at
/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:2167
#3  0x00000000006c15b6 in resolve_dynamic_type_internal (type=0x220de20, 
    addr_stack=0x7fffffffc9b0, top_level=1)
    at /home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:2590
#4  0x00000000006c1799 in resolve_dynamic_type (type=0x220de20, valaddr=...,
addr=4199637)
    at /home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:2635
#5  0x0000000000aa4f79 in value_from_contents_and_address (type=0x220de20,
valaddr=0x0, 
    address=4199637) at /home/vries/gdb_versions/devel/src/gdb/value.c:3494
#6  0x0000000000a8d546 in get_value_at (type=0x220de20, addr=4199637, lazy=1)
    at /home/vries/gdb_versions/devel/src/gdb/valops.c:899
#7  0x0000000000a8d5b4 in value_at_lazy (type=0x220de20, addr=4199637)
    at /home/vries/gdb_versions/devel/src/gdb/valops.c:936
#8  0x0000000000603f02 in dwarf2_evaluate_loc_desc_full (type=0x220de20,
frame=0xa6cfcc0, 
    data=0x21f9dca "\221\230\177\006\tg", size=4, per_cu=0x21f20c0,
per_objfile=0x1f527d0, 
    subobj_type=0x220de20, subobj_byte_offset=0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/loc.c:2364
#9  0x00000000006042b9 in dwarf2_evaluate_loc_desc (type=0x220de20,
frame=0xa6cfcc0, 
    data=0x21f9dca "\221\230\177\006\tg", size=4, per_cu=0x21f20c0,
per_objfile=0x1f527d0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/loc.c:2444
#10 0x00000000006067d5 in locexpr_read_variable (symbol=0x220e200,
frame=0xa6cfcc0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/loc.c:3688
#11 0x000000000069b777 in language_defn::read_var_value (this=0x1582180
<f_language_defn>, 
    var=0x220e200, var_block=0x0, frame=0xa6cfcc0)
    at /home/vries/gdb_versions/devel/src/gdb/findvar.c:618
#12 0x000000000069c27b in read_var_value (var=0x220e200, var_block=0x0,
frame=0xa6cfcc0)
    at /home/vries/gdb_versions/devel/src/gdb/findvar.c:822
#13 0x000000000099129d in read_frame_arg (fp_opts=..., sym=0x220e200,
frame=0xa6cfcc0, 
    argp=0x7fffffffcf10, entryargp=0x7fffffffcf30)
    at /home/vries/gdb_versions/devel/src/gdb/stack.c:542
#14 0x0000000000991e74 in print_frame_args (fp_opts=..., func=0x220df40,
frame=0xa6cfcc0, 
    num=-1, stream=0x21c2fc0) at
/home/vries/gdb_versions/devel/src/gdb/stack.c:884
#15 0x0000000000993085 in print_frame (fp_opts=..., frame=0xa6cfcc0,
print_level=1, 
    print_what=LOCATION, print_args=1, sal=...)
    at /home/vries/gdb_versions/devel/src/gdb/stack.c:1388
#16 0x0000000000992741 in print_frame_info (fp_opts=..., frame=0xa6cfcc0,
print_level=1, 
    print_what=LOCATION, print_args=1, set_current_sal=0)
    at /home/vries/gdb_versions/devel/src/gdb/stack.c:1113
#17 0x000000000099469a in backtrace_command_1 (fp_opts=..., bt_opts=...,
count_exp=0x0, 
    from_tty=0) at /home/vries/gdb_versions/devel/src/gdb/stack.c:2079
#18 0x0000000000994aca in backtrace_command (arg=0x0, from_tty=0)
    at /home/vries/gdb_versions/devel/src/gdb/stack.c:2198
#19 0x0000000000545eb9 in do_const_cfunc (c=0x1e9a430, args=0x0, from_tty=0)
    at /home/vries/gdb_versions/devel/src/gdb/cli/cli-decode.c:95
#20 0x000000000054958b in cmd_func (cmd=0x1e9a430, args=0x0, from_tty=0)
    at /home/vries/gdb_versions/devel/src/gdb/cli/cli-decode.c:2181
#21 0x0000000000a0c3db in execute_command (p=0x7fffffffe1b4 "", from_tty=0)
    at /home/vries/gdb_versions/devel/src/gdb/top.c:668
#22 0x00000000007998d4 in catch_command_errors (
    command=0xa0be66 <execute_command(char const*, int)>, arg=0x7fffffffe1b2
"bt", 
    from_tty=0) at /home/vries/gdb_versions/devel/src/gdb/main.c:457
#23 0x000000000079acb2 in captured_main_1 (context=0x7fffffffdaa0)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1218
#24 0x000000000079aea7 in captured_main (data=0x7fffffffdaa0)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1243
#25 0x000000000079af12 in gdb_main (args=0x7fffffffdaa0)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1268
#26 0x0000000000417efe in main (argc=15, argv=0x7fffffffdba8)
    at /home/vries/gdb_versions/devel/src/gdb/gdb.c:32
...
we lost the frame context, and use the current frame at level 0:
...
2581      if (frame == NULL && has_stack_frames ())
(gdb) 
2582        frame = get_selected_frame (NULL);
(gdb) 
2584      switch (prop->kind ())
(gdb) p frame
$19 = (frame_info *) 0x21fcf80
(gdb) p *frame
$20 = {level = 0, pspace = 0x1ec45d0, aspace = 0x1ec7630, prologue_cache =
0x21fd040, 
  unwind = 0xd964a0 <dwarf2_frame_unwind>, prev_arch = {p = true, arch =
0x2233ae0}, 
  prev_pc = {status = CC_VALUE, masked = false, value = 4199219}, prev_func = {
    addr = 4199210, status = CC_VALUE}, this_id = {p = true, value = {
      stack_addr = 140737488344368, code_addr = 4198073, special_addr = 0, 
      stack_status = FID_STACK_VALID, code_addr_p = 1, special_addr_p = 0, 
      artificial_depth = 0}}, base = 0x0, base_cache = 0x0, next = 0x21fceb0,
prev_p = true, 
  prev = 0xa6c0a50, stop_reason = UNWIND_NO_REASON, stop_string = 0x0}
...
while a bit up in the backtrace, we have the frame in which we actually want to
do the evaluation, at level 7:
....
(gdb) 
#8  0x0000000000603f02 in dwarf2_evaluate_loc_desc_full (type=0x220de20,
frame=0xa6cfcc0, 
    data=0x21f9dca "\221\230\177\006\tg", size=4, per_cu=0x21f20c0,
per_objfile=0x1f527d0, 
    subobj_type=0x220de20, subobj_byte_offset=0)
    at /home/vries/gdb_versions/devel/src/gdb/dwarf2/loc.c:2364
2364                retval = value_at_lazy (subobj_type,
(gdb) p *frame
$21 = {level = 7, pspace = 0x1ec45d0, aspace = 0x1ec7630, prologue_cache =
0xa6cfd80, 
  unwind = 0xd964a0 <dwarf2_frame_unwind>, prev_arch = {p = true, arch =
0x2233ae0}, 
  prev_pc = {status = CC_VALUE, masked = false, value = 4198289}, prev_func = {
    addr = 4198183, status = CC_VALUE}, this_id = {p = true, value = {
      stack_addr = 140737488345360, code_addr = 4198296, special_addr = 0, 
      stack_status = FID_STACK_VALID, code_addr_p = 1, special_addr_p = 0, 
      artificial_depth = 0}}, base = 0x0, base_cache = 0x0, next = 0xa6cc710,
prev_p = true, 
  prev = 0xa6d4260, stop_reason = UNWIND_NO_REASON, stop_string = 0x0}
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Tentative patch, code copied from print_frame_local_vars:
...
diff --git a/gdb/stack.c b/gdb/stack.c
index 265e764dc2..b63f109031 100644
--- a/gdb/stack.c
+++ b/gdb/stack.c
@@ -743,6 +743,12 @@ print_frame_args (const frame_print_options &fp_opts,
   bool print_args
     = (print_names
        && fp_opts.print_frame_arguments != print_frame_arguments_none);
+
+  /* Temporarily change the selected frame to the given FRAME.
+     This allows routines that rely on the selected frame instead
+     of being given a frame as parameter to use the correct frame.  */
+  scoped_restore_selected_frame restore_selected_frame;
+  select_frame (frame);

   if (func)
     {
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brobecke at sourceware dot org

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)
> Tentative patch, code copied from print_frame_local_vars:
> ...
> diff --git a/gdb/stack.c b/gdb/stack.c
> index 265e764dc2..b63f109031 100644
> --- a/gdb/stack.c
> +++ b/gdb/stack.c
> @@ -743,6 +743,12 @@ print_frame_args (const frame_print_options &fp_opts,
>    bool print_args
>      = (print_names
>         && fp_opts.print_frame_arguments != print_frame_arguments_none);
> +
> +  /* Temporarily change the selected frame to the given FRAME.
> +     This allows routines that rely on the selected frame instead
> +     of being given a frame as parameter to use the correct frame.  */
> +  scoped_restore_selected_frame restore_selected_frame;
> +  select_frame (frame);
>  
>    if (func)
>      {
> ...

Yep, the problem sounds rather similar to what is described here: 
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=16c3b12f199a7ec99a0b51bd83b66942547bba87
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 12772
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12772&action=edit
Tentative patch with test-case

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|symtab                      |backtrace

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
Posted patch:
https://sourceware.org/pipermail/gdb-patches/2020-August/171297.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=547ce8f00b4ef826bdc9bf9a74f119fe9768852e

commit 547ce8f00b4ef826bdc9bf9a74f119fe9768852e
Author: Tom de Vries <tdevries@suse.de>
Date:   Sat Aug 15 10:19:13 2020 +0200

    [gdb/backtrace] Fix printing of fortran string args

    When running test-case gdb.fortran/mixed-lang-stack.exp, it passes, but we
    find in gdb.log:
    ...
     (gdb) bt^M
       ...
     #7  0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
       e=<error reading variable: value requires 140737488341744 bytes, which \
       is more than max-value-size>, g=..., _e=6) at mixed-lang-stack.f90:87^M
    ...
    while a bit later in gdb.log, we have instead for the same frame (after
    adding a gdb_test_no_output "set print frame-arguments all" to prevent
    getting "e=..."):
    ...
     (gdb) up^M
     #7  0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
       e='abcdef', g=( a = 1.5, b = 2.5 ), _e=6) at mixed-lang-stack.f90:87^M
    ...

    The difference is that in the latter case, we print the frame while it's
    selected, while in the former, it's not.

    The problem is that while trying to resolve the dynamic type of e in
    resolve_dynamic_type, we call dwarf2_evaluate_property with a frame == NULL
    argument, and then use the selected frame as the context in which to
evaluate
    the dwarf property, effectively evaluating a DW_OP_fbreg operation in the
    wrong frame context.

    Fix this by temporarily selecting the frame of which we're trying to print
the
    arguments in print_frame_args, borrowing code from print_frame_local_vars
that
    was added to fix a similar issue in commit 16c3b12f19 "error/internal-error
    printing local variable during "bt full".

    Build and tested on x86_64-linux.

    gdb/ChangeLog:

    2020-08-15  Tom de Vries  <tdevries@suse.de>

            PR backtrace/26390
            * stack.c (print_frame_args): Temporarily set the selected
            frame to FRAME while printing the frame's arguments.

    gdb/testsuite/ChangeLog:

    2020-08-15  Tom de Vries  <tdevries@suse.de>

            PR backtrace/26390
            * gdb.fortran/mixed-lang-stack.exp: Call bt with -frame-arguments
all.
            Update expected pattern.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.1

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> I tried to use recursive_dump_type to print the type, but ran into an
> assert, because recursive_dump_type tries to print the high bound as
> PROP_CONST, while it's a PROP_LOCEXPR.  Tentative patch:
> ...
> diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
> index da1c58c65c..d3f460779a 100644
> --- a/gdb/gdbtypes.c
> +++ b/gdb/gdbtypes.c
> @@ -4856,6 +4856,27 @@ print_gnat_stuff (struct type *type, int spaces)
>  
>  static struct obstack dont_print_type_obstack;
>  
> +static void
> +dump_dynamic_prop (dynamic_prop &prop)
> +{
> +  switch (prop.kind ())
> +    {
> +    case PROP_CONST:
> +      printfi_filtered (0, "%s", plongest (prop.const_val ()));
> +      break;
> +    case PROP_UNDEFINED:
> +      printfi_filtered (0, "(undefined)");
> +      break;
> +    case PROP_LOCEXPR:
> +    case PROP_LOCLIST:
> +      printfi_filtered (0, "(dynamic)");
> +      break;
> +    default:
> +      gdb_assert (false);
> +      break;
> +    }
> +}
> +
>  void
>  recursive_dump_type (struct type *type, int spaces)
>  {
> @@ -5115,13 +5136,11 @@ recursive_dump_type (struct type *type, int spaces)
>      }
>    if (type->code () == TYPE_CODE_RANGE)
>      {
> -      printfi_filtered (spaces, "low %s%s  high %s%s\n",
> -                       plongest (type->bounds ()->low.const_val ()),
> -                       (type->bounds ()->low.kind () == PROP_UNDEFINED
> -                        ? " (undefined)" : ""),
> -                       plongest (type->bounds ()->high.const_val ()),
> -                       (type->bounds ()->high.kind () == PROP_UNDEFINED
> -                        ? " (undefined)" : ""));
> +      printfi_filtered (spaces, "low ");
> +      dump_dynamic_prop (type->bounds ()->low);
> +      printfi_filtered (0, "  high ");
> +      dump_dynamic_prop (type->bounds ()->high);
> +      printfi_filtered (0, "\n");
>      }
>  
>    switch (TYPE_SPECIFIC_FIELD (type))
> ...

Filed as PR26393.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug backtrace/26390] gdb.fortran/mixed-lang-stack.exp: error reading variable in backtrace

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26390

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
fix and test-case update committed, marking resolved-fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.