Bug 27341 - [dwarf-5] FAIL: gdb.fortran/function-calls.exp: p derived_types_and_module_calls::pass_cart_nd(c_nd)
Summary: [dwarf-5] FAIL: gdb.fortran/function-calls.exp: p derived_types_and_module_ca...
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: fortran (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 10.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-03 22:39 UTC by Tom de Vries
Modified: 2023-03-20 09:55 UTC (History)
27 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2021-02-03 22:39:32 UTC
When running test-case gdb.fortran/function-calls.exp with target board unix/gdb:debug_flags=-gdwarf-5, I run into:
...
(gdb) PASS: gdb.fortran/function-calls.exp: p derived_types_and_module_calls::pass_cart(c)
p derived_types_and_module_calls::pass_cart_nd(c_nd)^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x0000000000400f73 in derived_types_and_module_calls::pass_cart_nd (c=<error reading variable: Cannot access memory at address 0xc>) at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/function-calls.f90:130^M
130             pass_cart_nd = ubound(c%d,1,4)^M
The program being debugged was signaled while in a function called from GDB.^M
GDB has restored the context to what it was before the call.^M
To change this behavior use "set unwindonsignal off".^M
Evaluation of the expression containing the function^M
(derived_types_and_module_calls::pass_cart_nd) will be abandoned.^M
(gdb) FAIL: gdb.fortran/function-calls.exp: p derived_types_and_module_calls::pass_cart_nd(c_nd)
...
Comment 1 Tom de Vries 2021-02-04 07:53:08 UTC
$ gdb -iex "set trace-commands on" -batch \
  outputs/gdb.fortran/function-calls/function-calls \
  -ex "break 241" \
  -ex "run" \
  -ex "p c_nd" \
  -ex "p derived_types_and_module_calls::pass_cart_nd(c_nd)"
+break 241
Breakpoint 1 at 0x4018bc: file function-calls.f90, line 241.
+run
             (2.09999990,3.29999995)
           4           5
          23
             (2.09999990,3.29999995)
   3.40000010    
           6
 

Breakpoint 1, function_calls () at function-calls.f90:241
241         deallocate(c_nd%d) ! post_init
+p c_nd
Cannot access memory at address 0x4
+p derived_types_and_module_calls::pass_cart_nd(c_nd)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000400f93 in derived_types_and_module_calls::pass_cart_nd (c=<error reading variable: Cannot access memory at address 0xc>) at /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.fortran/function-calls.f90:130
130             pass_cart_nd = ubound(c%d,1,4)
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(derived_types_and_module_calls::pass_cart_nd) will be abandoned.
When the function is done executing, GDB will silently stop.
Comment 2 Tom de Vries 2021-02-04 09:48:43 UTC
This is due to missing support for DW_TAG_generic_subrange in read_array_type.

So we have:
...
 <1><e1e>: Abbrev Number: 46 (DW_TAG_array_type)
    <e1f>   DW_AT_data_location: 2 byte block: 97 6     (DW_OP_push_object_address; DW_OP_deref)
    <e22>   DW_AT_rank        : 6 byte block: 97 23 10 6 37 1a
    <e29>   DW_AT_type        : <0x139>
    <e2d>   DW_AT_sibling     : <0xe51>
 <2><e31>: Abbrev Number: 47 (DW_TAG_generic_subrange)
    <e32>   DW_AT_lower_bound : 8 byte block: 97 14 48 1e 23 20 22 6    (DW_OP_push_object_address; DW_OP_over; DW_OP_lit24; DW_OP_mul; DW_OP_plus_uconst: 32; DW_OP_plus; DW_OP_deref)
    <e3b>   DW_AT_upper_bound : 8 byte block: 97 14 48 1e 23 28 22 6    (DW_OP_push_object_address; DW_OP_over; DW_OP_lit24; DW_OP_mul; DW_OP_plus_uconst: 40; DW_OP_plus; DW_OP_deref)
    <e44>   DW_AT_byte_stride : 11 byte block: 97 14 48 1e 23 18 22 6 8 38 1e   (DW_OP_push_object_address; DW_OP_over; DW_OP_lit24; DW_OP_mul; DW_OP_plus_uconst: 24; DW_OP_plus; DW_OP_deref; DW_OP_const1u: 56; DW_OP_mul)
...

We start out in read_array_type with:
...
  type = element_type;
...
and then iterate over range_types to build up the type further.

But there are no DW_TAG_subrange_type children (only one DW_TAG_generic_subrange), so range_types is empty, and type is kept unmodified.

Consequently, in set_die_type we apply the DW_AT_data_location to the element_type (the one at 0x139) instead of to the newly build array type.

Then we try to print c_nd:
...
 <2><6e8>: Abbrev Number: 2 (DW_TAG_variable)
    <6e9>   DW_AT_name        : (indirect string, offset: 0x218): c_nd
    <6ed>   DW_AT_decl_file   : 1
    <6ed>   DW_AT_decl_line   : 198
    <6ee>   DW_AT_type        : <0x139>
    <6f2>   DW_AT_location    : 9 byte block: 3 e0 30 60 0 0 0 0 0      (DW_OP_addr: 6030e0)
...
and find that the type has a data_location property, which when used gives incorrect results.
Comment 4 Sourceware Commits 2021-02-09 22:28:20 UTC
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit cf2b20752995e6f10d88afc49166e729c33beb48
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Feb 9 23:28:16 2021 +0100

    [gdb/symtab] Fix element type modification in read_array_type
    
    When running test-case gdb.fortran/function-calls.exp with target board
    unix/gdb:debug_flags=-gdwarf-5, I run into:
    ...
    (gdb) PASS: gdb.fortran/function-calls.exp: \
      p derived_types_and_module_calls::pass_cart(c)
    p derived_types_and_module_calls::pass_cart_nd(c_nd)^M
    ^M
    Program received signal SIGSEGV, Segmentation fault.^M
    0x0000000000400f73 in derived_types_and_module_calls::pass_cart_nd \
      (c=<error reading variable: Cannot access memory at address 0xc>) at \
      function-calls.f90:130^M
    130             pass_cart_nd = ubound(c%d,1,4)^M
    The program being debugged was signaled while in a function called from GDB.^M
    GDB has restored the context to what it was before the call.^M
    To change this behavior use "set unwindonsignal off".^M
    Evaluation of the expression containing the function^M
    (derived_types_and_module_calls::pass_cart_nd) will be abandoned.^M
    (gdb) FAIL: gdb.fortran/function-calls.exp: p
    ...
    
    The problem originates in read_array_type, when reading a DW_TAG_array_type
    with a dwarf-5 DW_TAG_generic_subrange child.  This is not supported, and the
    fallout of this is that rather than constructing a new array type, the code
    proceeds to modify the element type.
    
    Fix this conservatively by issuing a complaint and bailing out in
    read_array_type when not being able to construct an array type, such that we
    have:
    ...
    (gdb) maint expand-symtabs function-calls.f90^M
    During symbol reading: unable to find array range \
      - DIE at 0xe1e [in module function-calls]^M
    During symbol reading: unable to find array range \
      - DIE at 0xe1e [in module function-calls]^M
    (gdb) KFAIL: gdb.fortran/function-calls.exp: no complaints in srcfile \
      (PRMS: symtab/27388)
    ...
    
    Tested on x86_64-linux.
    
    gdb/ChangeLog:
    
    2021-02-09  Tom de Vries  <tdevries@suse.de>
    
            PR symtab/27341
            * dwarf2/read.c (read_array_type): Return NULL when not being able to
            construct an array type.  Add assert to ensure that element_type is
            not being modified.
    
    gdb/testsuite/ChangeLog:
    
    2021-02-09  Tom de Vries  <tdevries@suse.de>
    
            PR symtab/27341
            * lib/gdb.exp (with_complaints): New proc, factored out of ...
            (gdb_load_no_complaints): ... here.
            * gdb.fortran/function-calls.exp: Add test-case.
Comment 5 Tom de Vries 2021-02-09 22:30:29 UTC
Patch with test-case committed, marking resolved-fixed.
Comment 6 Tom de Vries 2021-02-09 22:31:47 UTC
(In reply to Tom de Vries from comment #2)
> This is due to missing support for DW_TAG_generic_subrange in
> read_array_type.

Filed as PR27388 - [gdb, dwarf5] Support DW_TAG_generic_subrange
Comment 7 Sourceware Commits 2021-03-07 16:58:32 UTC
The gdb-10-branch branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit cdb986e09e09bff3b1c4fc935d6676b838623312
Author: Tom de Vries <tdevries@suse.de>
Date:   Sun Mar 7 17:58:28 2021 +0100

    [gdb/symtab] Fix element type modification in read_array_type
    
    When running test-case gdb.fortran/function-calls.exp with target board
    unix/gdb:debug_flags=-gdwarf-5, I run into:
    ...
    (gdb) PASS: gdb.fortran/function-calls.exp: \
      p derived_types_and_module_calls::pass_cart(c)
    p derived_types_and_module_calls::pass_cart_nd(c_nd)^M
    ^M
    Program received signal SIGSEGV, Segmentation fault.^M
    0x0000000000400f73 in derived_types_and_module_calls::pass_cart_nd \
      (c=<error reading variable: Cannot access memory at address 0xc>) at \
      function-calls.f90:130^M
    130             pass_cart_nd = ubound(c%d,1,4)^M
    The program being debugged was signaled while in a function called from GDB.^M
    GDB has restored the context to what it was before the call.^M
    To change this behavior use "set unwindonsignal off".^M
    Evaluation of the expression containing the function^M
    (derived_types_and_module_calls::pass_cart_nd) will be abandoned.^M
    (gdb) FAIL: gdb.fortran/function-calls.exp: p
    ...
    
    The problem originates in read_array_type, when reading a DW_TAG_array_type
    with a dwarf-5 DW_TAG_generic_subrange child.  This is not supported, and the
    fallout of this is that rather than constructing a new array type, the code
    proceeds to modify the element type.
    
    Fix this conservatively by issuing a complaint and bailing out in
    read_array_type when not being able to construct an array type, such that we
    have:
    ...
    (gdb) maint expand-symtabs function-calls.f90^M
    During symbol reading: unable to find array range \
      - DIE at 0xe1e [in module function-calls]^M
    During symbol reading: unable to find array range \
      - DIE at 0xe1e [in module function-calls]^M
    (gdb) KFAIL: gdb.fortran/function-calls.exp: no complaints in srcfile \
      (PRMS: symtab/27388)
    ...
    
    Tested on x86_64-linux.
    
    gdb/ChangeLog:
    
    2021-03-07  Tom de Vries  <tdevries@suse.de>
    
            PR symtab/27341
            * dwarf2/read.c (read_array_type): Return NULL when not being able to
            construct an array type.  Add assert to ensure that element_type is
            not being modified.
    
    gdb/testsuite/ChangeLog:
    
    2021-03-07  Tom de Vries  <tdevries@suse.de>
    
            PR symtab/27341
            * lib/gdb.exp (with_complaints): New proc, factored out of ...
            (gdb_load_no_complaints): ... here.
            * gdb.fortran/function-calls.exp: Add test-case.
Comment 8 Sherry 2021-07-15 01:35:37 UTC Comment hidden (spam)
Comment 9 Joe Anderson 2021-07-21 04:06:05 UTC Comment hidden (spam)
Comment 10 Madison Wilson 2021-08-09 09:41:16 UTC Comment hidden (spam)
Comment 12 james rohan 2021-09-02 11:05:39 UTC Comment hidden (spam)
Comment 13 james robin 2021-09-06 09:06:23 UTC Comment hidden (spam)
Comment 15 Mehmet gelisin 2021-09-10 19:40:49 UTC Comment hidden (spam)
Comment 16 Merve Gunesli 2021-09-22 16:40:09 UTC Comment hidden (spam)
Comment 17 Kylan 2021-09-26 13:31:44 UTC Comment hidden (spam)
Comment 18 Steve Anderson 2021-10-04 04:39:34 UTC Comment hidden (spam)
Comment 19 Zeinab B. 2021-10-05 04:33:00 UTC Comment hidden (spam)
Comment 20 Gulsen Engin 2021-10-09 11:00:20 UTC Comment hidden (spam)
Comment 21 Zeinab B. 2021-10-10 03:40:05 UTC Comment hidden (spam)
Comment 22 oficaj3 2021-10-10 16:11:02 UTC Comment hidden (spam)
Comment 23 Kyle 2021-10-11 11:26:50 UTC Comment hidden (spam)
Comment 24 Kyle Scott 2021-10-18 06:45:32 UTC Comment hidden (spam)
Comment 25 Canerkin 2021-10-18 19:57:55 UTC Comment hidden (spam)
Comment 26 Canerkin 2021-10-18 19:59:15 UTC Comment hidden (spam)
Comment 27 progonsaytu 2021-10-19 07:14:09 UTC Comment hidden (spam)
Comment 28 glassmtech 2021-10-24 10:02:05 UTC Comment hidden (spam)
Comment 29 Taylor Kimj 2021-10-25 08:20:52 UTC Comment hidden (spam)
Comment 30 ahappliancerepair1 2021-10-25 18:38:13 UTC Comment hidden (spam)
Comment 31 Kuka Kim 2021-10-29 10:57:02 UTC Comment hidden (spam)
Comment 32 Jordan Prest 2021-11-02 09:31:50 UTC Comment hidden (spam)
Comment 33 Audrey Smith 2021-11-04 09:21:38 UTC Comment hidden (spam)
Comment 34 Justin Louie 2021-11-05 09:27:25 UTC Comment hidden (spam)
Comment 35 Marulee 2021-11-08 11:50:40 UTC Comment hidden (spam)
Comment 36 Stewart 2021-11-09 11:45:25 UTC Comment hidden (spam)
Comment 37 Henry Moe 2021-11-17 13:02:59 UTC Comment hidden (spam)
Comment 38 George Barnett 2022-10-23 18:52:34 UTC Comment hidden (spam)
Comment 39 ali zaidi 2023-03-15 00:57:07 UTC Comment hidden (spam)
Comment 40 ali zaidi 2023-03-15 00:57:30 UTC Comment hidden (spam)
Comment 41 Qas Anwar 2023-03-20 09:55:54 UTC Comment hidden (spam)