Let's have following fortran program: ======= # nl -ba testprog.f90 1 program repro 2 3 call printslice('Hello world') 4 5 end program repro 6 7 8 subroutine printslice(stringgg) 9 character *(*) :: stringgg 10 11 print *, "stringgg: ", stringgg 12 13 end subroutine printslice 14 # ======= Let's compile this using baseos (rhel6 or rhel7) toolchain. Then run the resulting binary under gdb, stop at line 11 and print the contents of variable stringgg. It is "Hello world" as expected. However, when dts-6 toolchain (devtoolset-6-gcc-6.1.1-4.1.el[67], devtoolset-6-binutils-2.27-3.el[67]) gets used to compile the binary, we unexpectedly see this: ======= # gdb ./repro.dtstoolchain GNU gdb (GDB) Red Hat Enterprise Linux 7.11.1-77.el7 ... stuff deleted ... Reading symbols from ./repro.dtstoolchain...done. (gdb) l 1 program repro 2 3 call printslice('Hello world') 4 5 end program repro 6 7 8 subroutine printslice(stringgg) 9 character *(*) :: stringgg 10 (gdb) 11 print *, "stringgg: ", stringgg 12 13 end subroutine printslice 14 (gdb) b 11 Breakpoint 1 at 0x40074e: file testprog.f90, line 11. (gdb) r Starting program: /root/mcermak/repro.dtstoolchain Breakpoint 1, printslice (stringgg=..., _stringgg=11) at testprog.f90:11 11 print *, "stringgg: ", stringgg Missing separate debuginfos, use: debuginfo-install libgcc-4.8.5-9.el7.x86_64 libgfortran-4.8.5-9.el7.x86_64 libquadmath-4.8.5-9.el7.x86_64 (gdb) p stringgg $1 = 'H' (gdb) ======= However, e.g. systemtap can see the value of the stringgg variable correctly: ======= 7.3 S x86_64 [6] # stap -L 'process("./repro.dtstoolchain").statement("*@*:*")' -c ./repro.dtstoolchain process("/root/mcermak/repro.dtstoolchain").statement("main@/root/mcermak/testprog.f90:5") $argc:integer(kind=4) const $argv:character(kind=1)* process("/root/mcermak/repro.dtstoolchain").statement("printslice@/root/mcermak/testprog.f90:11") $_stringgg:integer(kind=4) const process("/root/mcermak/repro.dtstoolchain").statement("printslice@/root/mcermak/testprog.f90:13") $_stringgg:integer(kind=4) const process("/root/mcermak/repro.dtstoolchain").statement("printslice@/root/mcermak/testprog.f90:8") $_stringgg:integer(kind=4) const process("/root/mcermak/repro.dtstoolchain").statement("repro@/root/mcermak/testprog.f90:1") process("/root/mcermak/repro.dtstoolchain").statement("repro@/root/mcermak/testprog.f90:3") process("/root/mcermak/repro.dtstoolchain").statement("repro@/root/mcermak/testprog.f90:5") 7.3 S x86_64 [6] # stap -e 'probe process("/root/mcermak/repro.dtstoolchain").statement("printslice@/root/mcermak/testprog.f90:11") {println($_stringgg)}' -c ./repro.dtstoolchain stringgg: Hello world 11 7.3 S x86_64 [6] # ======= Applies to devtoolset-6-gdb-7.11.1-77.el[67] all supp arches.
Please ignore the last stap related part, sigh. It is invalid. The rest above that still applies.
Description of problem: Some GDB testcases started to failing F23->F24. Version-Release number of selected component (if applicable): PASS: gcc-5.3.1-2.fc23.x86_64 FAIL: gcc-6.1.1-3.fc24.x86_64 How reproducible: Always. Steps to Reproduce: cat >stringalloc.f90 <<EOH program stringalloc character(len=:), target, allocatable :: var_char allocate(character(len=10) :: var_char) var_char = 'foo' end program stringalloc EOH gfortran -o stringalloc stringalloc.f90 -Wall -g;gdb ./stringalloc -batch -ex 'b 5' -ex r -ex 'ptype var_char' Actual results: type = PTR TO -> ( character*1 ) <2><a4>: Abbrev Number: 8 (DW_TAG_variable) <a5> DW_AT_name : (indirect string, offset: 0x111): var_char <a9> DW_AT_decl_file : 1 <aa> DW_AT_decl_line : 2 <ab> DW_AT_type : <0xd1> <af> DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24) <1><d0>: Abbrev Number: 11 (DW_TAG_string_type) <1><d1>: Abbrev Number: 6 (DW_TAG_pointer_type) <d2> DW_AT_byte_size : 8 <d3> DW_AT_type : <0xd0> Expected results: type = PTR TO -> ( character*10 ) <2><4c>: Abbrev Number: 3 (DW_TAG_variable) <4d> DW_AT_name : (indirect string, offset: 0x111): var_char <51> DW_AT_decl_file : 1 <52> DW_AT_decl_line : 2 <53> DW_AT_type : <0x7d> <57> DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24) <1><78>: Abbrev Number: 6 (DW_TAG_string_type) <79> DW_AT_string_length: 2 byte block: 91 64 (DW_OP_fbreg: -28) <7c> DW_AT_byte_size : 4 <1><7d>: Abbrev Number: 7 (DW_TAG_pointer_type) <7e> DW_AT_byte_size : 8 <7f> DW_AT_type : <0x78> Additional info: There is also some additional unknown DIE but that does not seem to be related: <2><5a>: Abbrev Number: 4 (DW_TAG_variable) <5b> DW_AT_name : (indirect string, offset: 0x110): .var_char <5f> DW_AT_type : <0x83> <63> DW_AT_artificial : 1 <63> DW_AT_location : 2 byte block: 91 64 (DW_OP_fbreg: -28) <1><83>: Abbrev Number: 8 (DW_TAG_base_type) <84> DW_AT_byte_size : 4 <85> DW_AT_encoding : 5 (signed) <86> DW_AT_name : (indirect string, offset: 0xeb): integer(kind=4)
*** Bug 1357207 has been marked as a duplicate of this bug. ***
So when testing with devtoolset-6-gcc-6.3.1-2.2.el[67], the following happens: ==================================================== 1) Both dts-6.1 ----> it works OK. Building: devtoolset-6-gcc-gfortran-6.3.1-2.2.el7 Debugging: devtoolset-6-gdb-7.12-40.el7 Breakpoint 1, printslice (stringgg=..., _stringgg=11) at testprog.f90:11 11 print *, "stringgg: ", stringgg $1 = 'Hello world' ==================================================== 2) gdb from dts-6.1 and gcc from RHEL ----> it works OK. Building: gcc-gfortran-4.8.5-11.el7 Debugging: devtoolset-6-gdb-7.12-40.el7 --- The same as above. --- ==================================================== 3) gcc from dts-6.1, gdb from RHEL ----> does not work, segfaults, ... Building: devtoolset-6-gcc-gfortran-6.3.1-2.2.el7 Debugging: gdb-7.6.1-94.el7 aarch64: Breakpoint 1 at 0x4008b0: file testprog.f90, line 11. stringgg: Hello world Segmentation fault s390x: Breakpoint 1, printslice (stringgg='Hello world', _stringgg=11) at testprog.f90:11 11 print *, "stringgg: ", stringgg $1 = batch.gdb:3: Error in sourced command file: Unhandled dwarf expression opcode 0xd others: Breakpoint 1, printslice (stringgg='Hello world', _stringgg=11) at testprog.f90:11 11 print *, "stringgg: ", stringgg $1 = batch.gdb:3: Error in sourced command file: Unhandled dwarf expression opcode 0x ----> However, I think we do not expect this to work. Please correct me if I am wrong. ==================================================== 4) Both from RHEL ----> it works OK. Building: gcc-gfortran-4.8.5-11.el7 Debugging: gdb-7.6.1-94.el7 ----> This is expected situation and not subject of the bug. ==================================================== When trying the scenario from comment #2, when using devtoolset-6-gcc-gfortran-6.3.1-2.2.el7, both RHEL and DTS gdb show the correct output: type = PTR TO -> ( character*10 ) Also, the attached testcase passed in devtoolset-6.1 Alpha test run. ----> Thus, I think we may claim that the original issue is fixed. However, as I said, I hope we do not expect dts-built binaries being understandable by RHEL gdb.
Also please note, that the released version of DTS-6.0 does not seem to suffer from this issue. It applies to DTS-6.0 Alpha only.
(In reply to Michael Petlan from comment #7) > ==================================================== > 3) gcc from dts-6.1, gdb from RHEL ----> does not work, segfaults, ... > > Building: devtoolset-6-gcc-gfortran-6.3.1-2.2.el7 > Debugging: gdb-7.6.1-94.el7 [...] > Breakpoint 1 at 0x4008b0: file testprog.f90, line 11. > stringgg: Hello world > Segmentation fault [...] > ----> However, I think we do not expect this to work. Please correct me if I > am wrong. Right, we do not expect it to work. Original RHEL-7 gfortran: <1><7e>: Abbrev Number: 6 (DW_TAG_string_type) <7f> DW_AT_string_length: 3 byte block: 91 84 7c (DW_OP_fbreg: -508) <83> DW_AT_byte_size : 4 New DTS (tested on Fedora 25) gfortran: <1><f0>: Abbrev Number: 11 (DW_TAG_string_type) <f1> DW_AT_string_length: 5 byte block: 99 d1 0 0 0 (DW_OP_call4: <0xd1>) <f7> DW_AT_byte_size : 4 <2><d1>: Abbrev Number: 9 (DW_TAG_formal_parameter) <d2> DW_AT_name : (indirect string, offset: 0xc3): _stringgg <d6> DW_AT_type : <0x74> <da> DW_AT_artificial : 1 <da> DW_AT_location : 3 byte block: 91 84 7c (DW_OP_fbreg: -508) > ----> Thus, I think we may claim that the original issue is fixed. However, > as I said, I hope we do not expect dts-built binaries being understandable > by RHEL gdb. I agree. (In reply to Michael Petlan from comment #8) > Also please note, that the released version of DTS-6.0 does not seem to > suffer from this issue. It applies to DTS-6.0 Alpha only. Aren't there some typos in this comment?
(In reply to Jan Kratochvil from comment #9) > > ----> Thus, I think we may claim that the original issue is fixed. However, > > as I said, I hope we do not expect dts-built binaries being understandable > > by RHEL gdb. > > I agree. > Great. Thanks for confirming. > (In reply to Michael Petlan from comment #8) > > Also please note, that the released version of DTS-6.0 does not seem to > > suffer from this issue. It applies to DTS-6.0 Alpha only. > > Aren't there some typos in this comment? You mean s/0/1/g, don't you... No, it is correct. Martin filed the bug against devtoolset-6-gcc-6.1.1-4.1.el[67] (see comment #0), which was in DTS-6.0 Alpha, but the final gcc version which landed in DTS-6.0 was devtoolset-6-gcc-6.2.1-3.1.el[67] and that one seems to work (and so does the DTS-6.1's devtoolset-6-gcc-6.3.1-2.2.el[67] (current)).
Testcase passes for: devtoolset-6-gcc-6.3.1-2.2.el[67] devtoolset-6-gdb-7.12-40.el[67] VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1143