* Re: [V4 00/21] Fortran dynamic array support [not found] ` <88072818E0A3D742B2B1AF16BBEC65A7263F0988@IRSMSX107.ger.corp.intel.com> @ 2016-08-16 13:59 ` Jan Kratochvil 2016-08-19 9:58 ` Bernhard Heckel 0 siblings, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2016-08-16 13:59 UTC (permalink / raw) To: Heckel, Bernhard; +Cc: Weinmann, Christoph T, gdb-patches [-- Attachment #1: Type: text/plain, Size: 3530 bytes --] Hi Bernhard, On Tue, 09 Aug 2016 09:55:05 +0200, Heckel, Bernhard wrote: > I took a look at "p varw" issue. > > >From my point of view, the debug information for the location of varw is wrong. > > Set a breakpoint at line 68 and run. > "P &varw" in GDB gives me same location as the print of "loc(z(2,4,6))" out of the fortran testcase. > Nevertheless, "loc(varw)" shows me a different location. Investigating on the dwarf debug info, GDB address calculation > of "varw" is correct. From my point of view, the location expression of "varw" is wrong. > > If you manual examine the content at "loc(varw)" you see the right content. > > FYI: I added a variable "dummy" in subroutine "foo" in order to get the content of fbreg and do manual address calculation. > > I attached the testcase + dwarf primarily Fedora 24 GDB (and many Fedora releases back) - with the older Intel VLA patch series - does PASS the testcase fine with gfortran DWARF so completely wrong the DWARF is not. Also you talk here only about starting address of 'varw'. But that is not a problem, the starting address in inferior + in GDB do match: varw(1, 1, 1) = 6 vs. $23 = (( ( 6, 5, 1, 5, 5) ( 3, 3, 3, 5, 5) ( 5, 5, 5, 3, 3) ( 3, 5, 5, 5, 5) ) ( ( 5, 3, 3, 3, 5) ( 5, 5, 5, 5, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ( ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ) (gdb) FAIL: gdb.fortran/dynamic.exp: p varw filled - the value 6 is really the first (1,1,1) value printed. The starting address is nothing special for GDB as starting address is adjusted/offseted by the inferior caller, GDB just reads the inferior-computed address. What is wrong is accessing 'varw' elements not in the first row of the array by GDB - because GDB needs to know the stride for it. Stride is described there in DWARF: <231> DW_AT_upper_bound : 11 byte block: 31 97 23 28 6 97 23 20 6 1c 22 (DW_OP_lit1; DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_minus; DW_OP_plus) <23d> DW_AT_byte_stride : 6 byte block: 97 23 18 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul) and that just fetches the values from gfortran array descriptor - otherwise the inferior Fortran function 'foo' would not work. Why do you think gfortran has the DWARF wrong? Do your GDB patches PASS with ifort? I no longer have ifort - I got a license from Markus Metzger many years ago, it was somehow complicated in Intel to get it for me and the license laster only one year. You would have to send me the ifort-built binary (or .s file). I have tried now to re-apply a part of the old working Intel VLA patch of value_subscripted_rvalue(): unsigned int elt_size = TYPE_LENGTH (elt_type); - unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound); + unsigned int elt_offs = longest_to_int (index - lowerbound); + LONGEST elt_stride = TYPE_BYTE_STRIDE (TYPE_INDEX_TYPE (array_type)); struct value *v; + if (elt_stride > 0) + elt_offs *= elt_stride; + else if (elt_stride < 0) + { + int offs = (elt_offs + 1) * elt_stride; + + elt_offs = TYPE_LENGTH (array_type) + offs; + } + else + elt_offs *= elt_size; + But it does not work (attached). Maybe because the stride of an array now appears to be stored into TYPE_FIELD_BITSIZE of the array itself (not its type) while with old Intel VLA patchset there was a special field TYPE_BYTE_STRIDE for that. Thanks, Jan [-- Attachment #2: 1 --] [-- Type: text/plain, Size: 2181 bytes --] --- ./gdb/valarith.c 2016-08-16 15:36:10.680313175 +0200 +++ ./gdb/valarith.c 2016-08-16 15:33:18.696930843 +0200 @@ -193,9 +193,22 @@ value_subscripted_rvalue (struct value * struct type *array_type = check_typedef (value_type (array)); struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type)); ULONGEST elt_size = type_length_units (elt_type); - ULONGEST elt_offs = elt_size * (index - lowerbound); + ULONGEST elt_offs = index - lowerbound; + LONGEST elt_stride = TYPE_FIELD_BITSIZE (array_type, 0); struct value *v; +if (elt_stride) fprintf(stderr,"value_subscripted_rvalue: elt_stride=%ld\n",elt_stride); + if (elt_stride > 0) + elt_offs *= elt_stride; + else if (elt_stride < 0) + { + int offs = (elt_offs + 1) * elt_stride; + + elt_offs = TYPE_LENGTH (array_type) + offs; + } + else + elt_offs *= elt_size; + if (index < lowerbound || (!TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED (array_type) && elt_offs >= type_length_units (array_type))) { --- ./gdb/valops.c 2016-08-16 15:36:10.694313288 +0200 +++ ./gdb/valops.c 2016-08-16 15:04:54.963343948 +0200 @@ -3826,7 +3826,7 @@ value_slice_1 (struct value *array, int struct type *elt_type = check_typedef (TYPE_TARGET_TYPE (array_type)); unsigned int elt_size, elt_offs; /* ATTRIBUTE_UNUSED: VLA bug: https://sourceware.org/ml/gdb-patches/2016-08/msg00099.html */ - LONGEST elt_stride ATTRIBUTE_UNUSED, ary_high_bound, ary_low_bound; + LONGEST elt_stride, ary_high_bound, ary_low_bound; struct value *v; int slice_range_size, i = 0, row_count = 1, elem_count = 1; @@ -3863,7 +3863,17 @@ value_slice_1 (struct value *array, int elt_offs = lowbound - ary_low_bound; elt_stride = TYPE_LENGTH (TYPE_INDEX_TYPE (array_type)); - elt_offs *= elt_size; +fprintf(stderr,"elt_stride=%d\n",elt_stride); + if (elt_stride > 0) + elt_offs *= elt_stride; + else if (elt_stride < 0) + { + int offs = (elt_offs + 1) * elt_stride; + + elt_offs = TYPE_LENGTH (array_type) + offs; + } + else + elt_offs *= elt_size; /* Check for valid user input. In case of Fortran this was already done in the calling function. */ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-16 13:59 ` [V4 00/21] Fortran dynamic array support Jan Kratochvil @ 2016-08-19 9:58 ` Bernhard Heckel 2016-08-21 17:04 ` Jan Kratochvil 0 siblings, 1 reply; 26+ messages in thread From: Bernhard Heckel @ 2016-08-19 9:58 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches On 16/08/2016 15:59, Jan Kratochvil wrote: > Hi Bernhard, > > On Tue, 09 Aug 2016 09:55:05 +0200, Heckel, Bernhard wrote: >> I took a look at "p varw" issue. >> >> >From my point of view, the debug information for the location of varw is wrong. >> >> Set a breakpoint at line 68 and run. >> "P &varw" in GDB gives me same location as the print of "loc(z(2,4,6))" out of the fortran testcase. >> Nevertheless, "loc(varw)" shows me a different location. Investigating on the dwarf debug info, GDB address calculation >> of "varw" is correct. From my point of view, the location expression of "varw" is wrong. >> >> If you manual examine the content at "loc(varw)" you see the right content. >> >> FYI: I added a variable "dummy" in subroutine "foo" in order to get the content of fbreg and do manual address calculation. >> >> I attached the testcase + dwarf > primarily Fedora 24 GDB (and many Fedora releases back) - with the older Intel > VLA patch series - does PASS the testcase fine with gfortran DWARF so > completely wrong the DWARF is not. > > Also you talk here only about starting address of 'varw'. But that is not > a problem, the starting address in inferior + in GDB do match: > varw(1, 1, 1) = 6 > vs. > $23 = (( ( 6, 5, 1, 5, 5) ( 3, 3, 3, 5, 5) ( 5, 5, 5, 3, 3) ( 3, 5, 5, 5, 5) ) ( ( 5, 3, 3, 3, 5) ( 5, 5, 5, 5, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ( ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ( 3, 3, 3, 3, 3) ) ) > (gdb) FAIL: gdb.fortran/dynamic.exp: p varw filled > - the value 6 is really the first (1,1,1) value printed. > The starting address is nothing special for GDB as starting address is > adjusted/offseted by the inferior caller, GDB just reads the inferior-computed > address. > > What is wrong is accessing 'varw' elements not in the first row of the array > by GDB - because GDB needs to know the stride for it. > Stride is described there in DWARF: > <231> DW_AT_upper_bound : 11 byte block: 31 97 23 28 6 97 23 20 6 1c 22 (DW_OP_lit1; DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_minus; DW_OP_plus) > <23d> DW_AT_byte_stride : 6 byte block: 97 23 18 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_lit4; DW_OP_mul) > and that just fetches the values from gfortran array descriptor - otherwise the > inferior Fortran function 'foo' would not work. > > Why do you think gfortran has the DWARF wrong? Do your GDB patches PASS with > ifort? I no longer have ifort - I got a license from Markus Metzger many > years ago, it was somehow complicated in Intel to get it for me and the > license laster only one year. You would have to send me the ifort-built > binary (or .s file). > > > I have tried now to re-apply a part of the old working Intel VLA patch of > value_subscripted_rvalue(): > unsigned int elt_size = TYPE_LENGTH (elt_type); > - unsigned int elt_offs = elt_size * longest_to_int (index - lowerbound); > + unsigned int elt_offs = longest_to_int (index - lowerbound); > + LONGEST elt_stride = TYPE_BYTE_STRIDE (TYPE_INDEX_TYPE (array_type)); > struct value *v; > > + if (elt_stride > 0) > + elt_offs *= elt_stride; > + else if (elt_stride < 0) > + { > + int offs = (elt_offs + 1) * elt_stride; > + > + elt_offs = TYPE_LENGTH (array_type) + offs; > + } > + else > + elt_offs *= elt_size; > + > > But it does not work (attached). Maybe because the stride of an array now > appears to be stored into TYPE_FIELD_BITSIZE of the array itself (not its type) > while with old Intel VLA patchset there was a special field TYPE_BYTE_STRIDE > for that. > > > Thanks, > Jan Hi Jan, here is the missing patch in your environment. https://sourceware.org/ml/gdb-patches/2015-01/msg00385.html This patch handles strides in DWARF and your fortran program. Christoph's patch series was about strides in user input, for example "print my_vla(1:10:2)" I will create a branch about all stride patches in the next weeks. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-19 9:58 ` Bernhard Heckel @ 2016-08-21 17:04 ` Jan Kratochvil 2016-08-23 13:34 ` Bernhard Heckel 0 siblings, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2016-08-21 17:04 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches On Fri, 19 Aug 2016 11:58:09 +0200, Bernhard Heckel wrote: > here is the missing patch in your environment. > https://sourceware.org/ml/gdb-patches/2015-01/msg00385.html > This patch handles strides in DWARF and your fortran program. OK, thanks, it does fix: -FAIL: gdb.fortran/dynamic.exp: p varw filled +PASS: gdb.fortran/dynamic.exp: p varw filled -FAIL: gdb.fortran/vla-stride.exp: print odd-elements +PASS: gdb.fortran/vla-stride.exp: print odd-elements -FAIL: gdb.fortran/vla-stride.exp: print last odd-element +PASS: gdb.fortran/vla-stride.exp: print last odd-element Although it regresses: print pvla^M -$7 = (5)^M -(gdb) PASS: gdb.fortran/vla-stride.exp: print single-element +value requires 4294967288 bytes, which is more than max-value-size^M +(gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element -$8 = 5^M -(gdb) PASS: gdb.fortran/vla-stride.exp: print one single-element +Insufficient memory in host GDB for object of size 4294967288 bytes, maximum allowed 536870911 bytes.^M +(gdb) FAIL: gdb.fortran/vla-stride.exp: print one single-element > I will create a branch about all stride patches in the next weeks. That would be probably best, thanks. Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-21 17:04 ` Jan Kratochvil @ 2016-08-23 13:34 ` Bernhard Heckel 2016-08-25 17:06 ` Jan Kratochvil 2016-09-01 9:48 ` Jan Kratochvil 0 siblings, 2 replies; 26+ messages in thread From: Bernhard Heckel @ 2016-08-23 13:34 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches On 21/08/2016 19:03, Jan Kratochvil wrote: > On Fri, 19 Aug 2016 11:58:09 +0200, Bernhard Heckel wrote: >> here is the missing patch in your environment. >> https://sourceware.org/ml/gdb-patches/2015-01/msg00385.html >> This patch handles strides in DWARF and your fortran program. > OK, thanks, it does fix: > -FAIL: gdb.fortran/dynamic.exp: p varw filled > +PASS: gdb.fortran/dynamic.exp: p varw filled > -FAIL: gdb.fortran/vla-stride.exp: print odd-elements > +PASS: gdb.fortran/vla-stride.exp: print odd-elements > -FAIL: gdb.fortran/vla-stride.exp: print last odd-element > +PASS: gdb.fortran/vla-stride.exp: print last odd-element > > Although it regresses: > print pvla^M > -$7 = (5)^M > -(gdb) PASS: gdb.fortran/vla-stride.exp: print single-element > +value requires 4294967288 bytes, which is more than max-value-size^M > +(gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element > -$8 = 5^M > -(gdb) PASS: gdb.fortran/vla-stride.exp: print one single-element > +Insufficient memory in host GDB for object of size 4294967288 bytes, maximum allowed 536870911 bytes.^M > +(gdb) FAIL: gdb.fortran/vla-stride.exp: print one single-element > > >> I will create a branch about all stride patches in the next weeks. > That would be probably best, thanks. > > > Jan Hi Jan, created a branch with all stride patches. I don't see regression on RH7.1, gcc 4.8.3-9 Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-23 13:34 ` Bernhard Heckel @ 2016-08-25 17:06 ` Jan Kratochvil 2016-08-25 17:22 ` Jan Kratochvil 2016-09-02 13:44 ` Bernhard Heckel 2016-09-01 9:48 ` Jan Kratochvil 1 sibling, 2 replies; 26+ messages in thread From: Jan Kratochvil @ 2016-08-25 17:06 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches [-- Attachment #1: Type: text/plain, Size: 1637 bytes --] On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote: > created a branch with all stride patches. users/bheckel/fortran-strides 2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b > I don't see regression on RH7.1, gcc 4.8.3-9 I see a regression for 32-bit targets (x86_64-m32 or native i686) on Fedora 24 (gcc-gfortran-6.1.1-3.fc24.x86_64). I do not see the regression on CentOS-7.2 (x86_64-m32). print pvla^M value requires 4294967288 bytes, which is more than max-value-size^M (gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element I have attached a fix. It is because: <115> DW_AT_lower_bound : 4 byte block: 97 23 10 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 16; DW_OP_deref) <11a> DW_AT_upper_bound : 4 byte block: 97 23 14 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 20; DW_OP_deref) <11f> DW_AT_byte_stride : 6 byte block: 97 23 c 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 12; DW_OP_deref; DW_OP_lit4; DW_OP_mul) DW_AT_lower_bound == 1 DW_AT_upper_bound == 1 DW_AT_byte_stride == (-2) * 4 == -8 I am not sure if gfortran is really wrong or not but a stride does not make sense for me for a single row array. Attaching also gdb.fortran/vla-stride.f90 from your branch built with gcc-gfortran-6.1.1-3.fc24.x86_64 on Fedora 24 x86_64 in -m32 mode. Besides that I see on all archs -FAIL: gdb.pascal/arrays.exp: Print dynamic array of string +FAIL: gdb.pascal/arrays.exp: Print dynamic array of string (GDB internal error) but that testcase is only in Fedora and the Pascal (fpc) support has been not well maintained so far so I am OK with that. Thanks, Jan [-- Attachment #2: 1 --] [-- Type: text/plain, Size: 797 bytes --] diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c index 88801ac..1fbf69a 100644 --- a/gdb/gdbtypes.c +++ b/gdb/gdbtypes.c @@ -1103,10 +1103,12 @@ create_array_type_with_stride (struct type *result_type, if (high_bound < low_bound) TYPE_LENGTH (result_type) = 0; else if (byte_stride > 0) - TYPE_LENGTH (result_type) = byte_stride * (high_bound - low_bound + 1); + TYPE_LENGTH (result_type) = (byte_stride * (high_bound - low_bound) + + TYPE_LENGTH (element_type)); else if (bit_stride > 0) TYPE_LENGTH (result_type) = - (bit_stride * (high_bound - low_bound + 1) + 7) / 8; + ((bit_stride * (high_bound - low_bound) + 7) / 8 + + TYPE_LENGTH (element_type)); else TYPE_LENGTH (result_type) = TYPE_LENGTH (element_type) * (high_bound - low_bound + 1); [-- Attachment #3: vla-stride.s --] [-- Type: text/plain, Size: 21421 bytes --] .file "vla-stride.f90" .text .Ltext0: .section .rodata .align 4 .LC0: .string "Integer overflow when calculating the amount of memory to allocate" .LC1: .string "vla" .align 4 .LC2: .string "Attempting to allocate already allocated variable '%s'" .align 4 .LC3: .string "At line 20 of file gdb.fortran/vla-stride.f90" .align 4 .LC4: .string "Allocation would exceed memory limit" .text .type MAIN__, @function MAIN__: .LFB0: .file 1 "gdb.fortran/vla-stride.f90" # gdb.fortran/vla-stride.f90:16 .loc 1 16 0 .cfi_startproc # BLOCK 2 seq:0 # PRED: ENTRY (FALLTHRU) pushl %ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl %esp, %ebp .cfi_def_cfa_register 5 pushl %edi pushl %esi pushl %ebx subl $60, %esp .cfi_offset 7, -12 .cfi_offset 6, -16 .cfi_offset 3, -20 # gdb.fortran/vla-stride.f90:17 .loc 1 17 0 movl $0, -72(%ebp) .LBB2: # gdb.fortran/vla-stride.f90:20 .loc 1 20 0 movl $0, %eax testl %eax, %eax # SUCC: 3 (FALLTHRU) 4 je .L2 # BLOCK 3 seq:1 # PRED: 2 (FALLTHRU) # gdb.fortran/vla-stride.f90:20 .loc 1 20 0 is_stmt 0 discriminator 1 subl $12, %esp pushl $.LC0 # SUCC: call _gfortran_runtime_error # BLOCK 4 seq:2 # PRED: 2 .L2: # gdb.fortran/vla-stride.f90:20 .loc 1 20 0 discriminator 2 movl -72(%ebp), %eax testl %eax, %eax # SUCC: 5 (FALLTHRU) 6 je .L3 # BLOCK 5 seq:3 # PRED: 4 (FALLTHRU) # gdb.fortran/vla-stride.f90:20 .loc 1 20 0 discriminator 3 subl $4, %esp pushl $.LC1 pushl $.LC2 pushl $.LC3 # SUCC: call _gfortran_runtime_error_at # BLOCK 6 seq:4 # PRED: 4 .L3: # gdb.fortran/vla-stride.f90:20 .loc 1 20 0 discriminator 4 subl $12, %esp pushl $40 call malloc addl $16, %esp movl %eax, -72(%ebp) movl -72(%ebp), %eax testl %eax, %eax # SUCC: 7 (FALLTHRU) 8 jne .L4 # BLOCK 7 seq:5 # PRED: 6 (FALLTHRU) # gdb.fortran/vla-stride.f90:20 .loc 1 20 0 discriminator 5 subl $12, %esp pushl $.LC4 # SUCC: call _gfortran_os_error # BLOCK 8 seq:6 # PRED: 6 .L4: # gdb.fortran/vla-stride.f90:20 .loc 1 20 0 discriminator 6 movl $265, -64(%ebp) movl $1, -56(%ebp) movl $10, -52(%ebp) movl $1, -60(%ebp) movl $-1, -68(%ebp) .LBB3: # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 is_stmt 1 discriminator 6 movl -72(%ebp), %edx movl -68(%ebp), %esi movl -56(%ebp), %ebx .LBB4: .LBB5: movl -72(%ebp), %eax testl %eax, %eax sete %al movzbl %al, %eax testl %eax, %eax # SUCC: 10 9 (FALLTHRU) jne .L5 # BLOCK 9 seq:7 # PRED: 8 (FALLTHRU) # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 is_stmt 0 discriminator 2 movl -56(%ebp), %ecx leal 9(%ecx), %edi movl -52(%ebp), %ecx cmpl %ecx, %edi # SUCC: 10 (FALLTHRU) 18 je .L6 # BLOCK 10 seq:8 # PRED: 8 9 (FALLTHRU) .L5: # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 3 testl %eax, %eax # SUCC: 11 (FALLTHRU) 12 je .L7 # BLOCK 11 seq:9 # PRED: 10 (FALLTHRU) # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 4 movl $0, %eax # SUCC: 13 [100.0%] jmp .L8 # BLOCK 12 seq:10 # PRED: 10 .L7: # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 5 movl -52(%ebp), %edx movl -56(%ebp), %eax subl %eax, %edx movl %edx, %eax addl $1, %eax movl $0, %edx testl %eax, %eax # SUCC: 13 (FALLTHRU) cmovs %edx, %eax # BLOCK 13 seq:11 # PRED: 12 (FALLTHRU) 11 [100.0%] .L8: # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 7 cmpl $10, %eax setne %al movzbl %al, %eax movl $1, -56(%ebp) movl $10, -52(%ebp) movl $1, -60(%ebp) movl -56(%ebp), %edx negl %edx movl %edx, -68(%ebp) movl -68(%ebp), %esi movl -56(%ebp), %ebx movl -72(%ebp), %edx testl %edx, %edx # SUCC: 14 (FALLTHRU) 15 jne .L9 # BLOCK 14 seq:12 # PRED: 13 (FALLTHRU) # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 8 subl $12, %esp pushl $40 call malloc addl $16, %esp movl %eax, -72(%ebp) movl $265, -64(%ebp) # SUCC: 17 [100.0%] jmp .L10 # BLOCK 15 seq:13 # PRED: 13 .L9: # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 9 testl %eax, %eax # SUCC: 16 (FALLTHRU) 17 je .L10 # BLOCK 16 seq:14 # PRED: 15 (FALLTHRU) # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 11 movl -72(%ebp), %eax subl $8, %esp pushl $40 pushl %eax call realloc addl $16, %esp # SUCC: 17 (FALLTHRU) movl %eax, -72(%ebp) # BLOCK 17 seq:15 # PRED: 16 (FALLTHRU) 15 14 [100.0%] .L10: # SUCC: 18 (FALLTHRU) # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 13 movl -72(%ebp), %edx # BLOCK 18 seq:16 # PRED: 9 17 (FALLTHRU) .L6: .LBE5: # SUCC: 19 (FALLTHRU) # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 14 movl $0, %eax # BLOCK 19 seq:17 # PRED: 18 (FALLTHRU) 20 [100.0%] .L12: # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 17 cmpl $9, %eax # SUCC: 21 20 (FALLTHRU) jg .L11 # BLOCK 20 seq:18 # PRED: 19 (FALLTHRU) # gdb.fortran/vla-stride.f90:21 .loc 1 21 0 discriminator 16 leal (%eax,%ebx), %ecx leal (%ecx,%esi), %edi movl A.1.3368(,%eax,4), %ecx movl %ecx, (%edx,%edi,4) addl $1, %eax # SUCC: 19 [100.0%] jmp .L12 # BLOCK 21 seq:19 # PRED: 19 .L11: .LBE4: .LBE3: # gdb.fortran/vla-stride.f90:23 .loc 1 23 0 is_stmt 1 movl $265, -40(%ebp) movl $1, -32(%ebp) movl $10, -28(%ebp) movl $-1, -36(%ebp) movl -72(%ebp), %eax movl -56(%ebp), %edx movl $10, %ecx subl %edx, %ecx movl %ecx, %edx sall $2, %edx addl %edx, %eax movl %eax, -48(%ebp) movl $1, -44(%ebp) .LBB6: # gdb.fortran/vla-stride.f90:24 .loc 1 24 0 movl $265, -40(%ebp) movl -36(%ebp), %eax movl $1, -32(%ebp) movl $10, -28(%ebp) movl %eax, %edx negl %edx movl %edx, -36(%ebp) movl -48(%ebp), %edx movl -32(%ebp), %ecx movl $10, %ebx subl %ecx, %ebx movl %ebx, %ecx imull %eax, %ecx sall $2, %ecx addl %ecx, %edx movl %edx, -48(%ebp) movl %eax, -44(%ebp) .LBE6: # gdb.fortran/vla-stride.f90:25 .loc 1 25 0 movl $265, -40(%ebp) movl $1, -32(%ebp) movl $5, -28(%ebp) movl $2, -36(%ebp) movl -72(%ebp), %eax movl -56(%ebp), %edx movl $1, %ecx subl %edx, %ecx movl %ecx, %edx sall $2, %edx addl %edx, %eax movl %eax, -48(%ebp) movl $-2, -44(%ebp) # gdb.fortran/vla-stride.f90:26 .loc 1 26 0 movl $265, -40(%ebp) movl $1, -32(%ebp) movl $1, -28(%ebp) movl $-2, -36(%ebp) movl -72(%ebp), %eax movl -56(%ebp), %edx movl $5, %ecx subl %edx, %ecx movl %ecx, %edx sall $2, %edx addl %edx, %eax movl %eax, -48(%ebp) movl $2, -44(%ebp) # gdb.fortran/vla-stride.f90:28 .loc 1 28 0 movl $0, -48(%ebp) .LBE2: # gdb.fortran/vla-stride.f90:29 .loc 1 29 0 nop leal -12(%ebp), %esp popl %ebx .cfi_restore 3 popl %esi .cfi_restore 6 popl %edi .cfi_restore 7 popl %ebp .cfi_restore 5 .cfi_def_cfa 4, 4 # SUCC: EXIT [100.0%] ret .cfi_endproc .LFE0: .size MAIN__, .-MAIN__ .globl main .type main, @function main: .LFB1: # gdb.fortran/vla-stride.f90:29 .loc 1 29 0 .cfi_startproc # BLOCK 2 seq:0 # PRED: ENTRY (FALLTHRU) leal 4(%esp), %ecx .cfi_def_cfa 1, 0 andl $-16, %esp pushl -4(%ecx) pushl %ebp .cfi_escape 0x10,0x5,0x2,0x75,0 movl %esp, %ebp pushl %ecx .cfi_escape 0xf,0x3,0x75,0x7c,0x6 subl $4, %esp movl %ecx, %eax # gdb.fortran/vla-stride.f90:29 .loc 1 29 0 subl $8, %esp pushl 4(%eax) pushl (%eax) call _gfortran_set_args addl $16, %esp subl $8, %esp pushl $options.3.3382 pushl $9 call _gfortran_set_options addl $16, %esp call MAIN__ movl $0, %eax movl -4(%ebp), %ecx .cfi_def_cfa 1, 0 leave .cfi_restore 5 leal -4(%ecx), %esp .cfi_def_cfa 4, 4 # SUCC: EXIT [100.0%] ret .cfi_endproc .LFE1: .size main, .-main .section .rodata .align 32 .type A.1.3368, @object .size A.1.3368, 40 A.1.3368: .long 1 .long 2 .long 3 .long 4 .long 5 .long 6 .long 7 .long 8 .long 9 .long 10 .align 32 .type options.3.3382, @object .size options.3.3382, 36 options.3.3382: .long 68 .long 1023 .long 0 .long 0 .long 1 .long 1 .long 0 .long 0 .long 31 .text .Letext0: .section .debug_info,"",@progbits .Ldebug_info0: .long 0x128 # Length of Compilation Unit Info .value 0x4 # DWARF version number .long .Ldebug_abbrev0 # Offset Into Abbrev. Section .byte 0x4 # Pointer Size (in bytes) .uleb128 0x1 # (DIE (0xb) DW_TAG_compile_unit) .long .LASF5 # DW_AT_producer: "GNU Fortran2008 6.1.1 20160621 (Red Hat 6.1.1-3) -m32 -mtune=generic -march=i686 -g -fintrinsic-modules-path /usr/lib/gcc/x86_64-redhat-linux/6.1.1/32/finclude" .byte 0xe # DW_AT_language .byte 0x2 # DW_AT_identifier_case .long .LASF6 # DW_AT_name: "gdb.fortran/vla-stride.f90" .long .LASF7 # DW_AT_comp_dir: "/home/jkratoch/redhat/gdb-clean/gdb/testsuite" .long .Ltext0 # DW_AT_low_pc .long .Letext0-.Ltext0 # DW_AT_high_pc .long .Ldebug_line0 # DW_AT_stmt_list .uleb128 0x2 # (DIE (0x26) DW_TAG_base_type) .byte 0x4 # DW_AT_byte_size .byte 0x5 # DW_AT_encoding .long .LASF2 # DW_AT_name: "integer(kind=4)" .uleb128 0x3 # (DIE (0x2d) DW_TAG_const_type) .long 0x26 # DW_AT_type .uleb128 0x4 # (DIE (0x32) DW_TAG_subprogram) # DW_AT_external .long .LASF8 # DW_AT_name: "main" .byte 0x1 # DW_AT_decl_file (gdb.fortran/vla-stride.f90) .byte 0x1d # DW_AT_decl_line .long 0x26 # DW_AT_type .long .LFB1 # DW_AT_low_pc .long .LFE1-.LFB1 # DW_AT_high_pc .uleb128 0x1 # DW_AT_frame_base .byte 0x9c # DW_OP_call_frame_cfa # DW_AT_GNU_all_tail_call_sites .long 0x69 # DW_AT_sibling .uleb128 0x5 # (DIE (0x4b) DW_TAG_formal_parameter) .long .LASF0 # DW_AT_name: "argc" .byte 0x1 # DW_AT_decl_file (gdb.fortran/vla-stride.f90) .byte 0x1d # DW_AT_decl_line .long 0x2d # DW_AT_type .uleb128 0x2 # DW_AT_location .byte 0x91 # DW_OP_fbreg .sleb128 0 .uleb128 0x5 # (DIE (0x59) DW_TAG_formal_parameter) .long .LASF1 # DW_AT_name: "argv" .byte 0x1 # DW_AT_decl_file (gdb.fortran/vla-stride.f90) .byte 0x1d # DW_AT_decl_line .long 0x69 # DW_AT_type .uleb128 0x3 # DW_AT_location .byte 0x91 # DW_OP_fbreg .sleb128 4 .byte 0x6 # DW_OP_deref .byte 0 # end of children of DIE 0x32 .uleb128 0x6 # (DIE (0x69) DW_TAG_pointer_type) .byte 0x4 # DW_AT_byte_size .long 0x6f # DW_AT_type .uleb128 0x2 # (DIE (0x6f) DW_TAG_base_type) .byte 0x1 # DW_AT_byte_size .byte 0x8 # DW_AT_encoding .long .LASF3 # DW_AT_name: "character(kind=1)" .uleb128 0x7 # (DIE (0x76) DW_TAG_subprogram) .long .LASF9 # DW_AT_name: "vla_stride" .byte 0x1 # DW_AT_decl_file (gdb.fortran/vla-stride.f90) .byte 0x10 # DW_AT_decl_line # DW_AT_main_subprogram .byte 0x2 # DW_AT_calling_convention .long .LFB0 # DW_AT_low_pc .long .LFE0-.LFB0 # DW_AT_high_pc .uleb128 0x1 # DW_AT_frame_base .byte 0x9c # DW_OP_call_frame_cfa # DW_AT_GNU_all_tail_call_sites .long 0xe7 # DW_AT_sibling .uleb128 0x8 # (DIE (0x8c) DW_TAG_variable) .ascii "i\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (gdb.fortran/vla-stride.f90) .byte 0x15 # DW_AT_decl_line .long 0x26 # DW_AT_type .uleb128 0x9 # (DIE (0x95) DW_TAG_variable) .long .LASF4 # DW_AT_name: "pvla" .byte 0x1 # DW_AT_decl_file (gdb.fortran/vla-stride.f90) .byte 0x12 # DW_AT_decl_line .long 0xe7 # DW_AT_type .uleb128 0x2 # DW_AT_location .byte 0x91 # DW_OP_fbreg .sleb128 -56 .uleb128 0xa # (DIE (0xa3) DW_TAG_variable) .ascii "vla\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (gdb.fortran/vla-stride.f90) .byte 0x11 # DW_AT_decl_line .long 0x10b # DW_AT_type .uleb128 0x3 # DW_AT_location .byte 0x91 # DW_OP_fbreg .sleb128 -80 .uleb128 0xb # (DIE (0xb2) DW_TAG_lexical_block) .long .LBB2 # DW_AT_low_pc .long .LBE2-.LBB2 # DW_AT_high_pc .uleb128 0xc # (DIE (0xbb) DW_TAG_lexical_block) .long .LBB3 # DW_AT_low_pc .long .LBE3-.LBB3 # DW_AT_high_pc .long 0xdc # DW_AT_sibling .uleb128 0xb # (DIE (0xc8) DW_TAG_lexical_block) .long .LBB4 # DW_AT_low_pc .long .LBE4-.LBB4 # DW_AT_high_pc .uleb128 0xd # (DIE (0xd1) DW_TAG_lexical_block) .long .LBB5 # DW_AT_low_pc .long .LBE5-.LBB5 # DW_AT_high_pc .byte 0 # end of children of DIE 0xc8 .byte 0 # end of children of DIE 0xbb .uleb128 0xd # (DIE (0xdc) DW_TAG_lexical_block) .long .LBB6 # DW_AT_low_pc .long .LBE6-.LBB6 # DW_AT_high_pc .byte 0 # end of children of DIE 0xb2 .byte 0 # end of children of DIE 0x76 .uleb128 0xe # (DIE (0xe7) DW_TAG_array_type) .uleb128 0x2 # DW_AT_data_location .byte 0x97 # DW_OP_push_object_address .byte 0x6 # DW_OP_deref .uleb128 0x4 # DW_AT_associated .byte 0x97 # DW_OP_push_object_address .byte 0x6 # DW_OP_deref .byte 0x30 # DW_OP_lit0 .byte 0x2e # DW_OP_ne .long 0x26 # DW_AT_type .long 0x10b # DW_AT_sibling .uleb128 0xf # (DIE (0xf8) DW_TAG_subrange_type) .uleb128 0x4 # DW_AT_lower_bound .byte 0x97 # DW_OP_push_object_address .byte 0x23 # DW_OP_plus_uconst .uleb128 0x10 .byte 0x6 # DW_OP_deref .uleb128 0x4 # DW_AT_upper_bound .byte 0x97 # DW_OP_push_object_address .byte 0x23 # DW_OP_plus_uconst .uleb128 0x14 .byte 0x6 # DW_OP_deref .uleb128 0x6 # DW_AT_byte_stride .byte 0x97 # DW_OP_push_object_address .byte 0x23 # DW_OP_plus_uconst .uleb128 0xc .byte 0x6 # DW_OP_deref .byte 0x34 # DW_OP_lit4 .byte 0x1e # DW_OP_mul .byte 0 # end of children of DIE 0xe7 .uleb128 0x10 # (DIE (0x10b) DW_TAG_array_type) .uleb128 0x2 # DW_AT_data_location .byte 0x97 # DW_OP_push_object_address .byte 0x6 # DW_OP_deref .uleb128 0x4 # DW_AT_allocated .byte 0x97 # DW_OP_push_object_address .byte 0x6 # DW_OP_deref .byte 0x30 # DW_OP_lit0 .byte 0x2e # DW_OP_ne .long 0x26 # DW_AT_type .uleb128 0xf # (DIE (0x118) DW_TAG_subrange_type) .uleb128 0x4 # DW_AT_lower_bound .byte 0x97 # DW_OP_push_object_address .byte 0x23 # DW_OP_plus_uconst .uleb128 0x10 .byte 0x6 # DW_OP_deref .uleb128 0x4 # DW_AT_upper_bound .byte 0x97 # DW_OP_push_object_address .byte 0x23 # DW_OP_plus_uconst .uleb128 0x14 .byte 0x6 # DW_OP_deref .uleb128 0x6 # DW_AT_byte_stride .byte 0x97 # DW_OP_push_object_address .byte 0x23 # DW_OP_plus_uconst .uleb128 0xc .byte 0x6 # DW_OP_deref .byte 0x34 # DW_OP_lit4 .byte 0x1e # DW_OP_mul .byte 0 # end of children of DIE 0x10b .byte 0 # end of children of DIE 0xb .section .debug_abbrev,"",@progbits .Ldebug_abbrev0: .uleb128 0x1 # (abbrev code) .uleb128 0x11 # (TAG: DW_TAG_compile_unit) .byte 0x1 # DW_children_yes .uleb128 0x25 # (DW_AT_producer) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x13 # (DW_AT_language) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x42 # (DW_AT_identifier_case) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x1b # (DW_AT_comp_dir) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x11 # (DW_AT_low_pc) .uleb128 0x1 # (DW_FORM_addr) .uleb128 0x12 # (DW_AT_high_pc) .uleb128 0x6 # (DW_FORM_data4) .uleb128 0x10 # (DW_AT_stmt_list) .uleb128 0x17 # (DW_FORM_sec_offset) .byte 0 .byte 0 .uleb128 0x2 # (abbrev code) .uleb128 0x24 # (TAG: DW_TAG_base_type) .byte 0 # DW_children_no .uleb128 0xb # (DW_AT_byte_size) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3e # (DW_AT_encoding) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .byte 0 .byte 0 .uleb128 0x3 # (abbrev code) .uleb128 0x26 # (TAG: DW_TAG_const_type) .byte 0 # DW_children_no .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .uleb128 0x4 # (abbrev code) .uleb128 0x2e # (TAG: DW_TAG_subprogram) .byte 0x1 # DW_children_yes .uleb128 0x3f # (DW_AT_external) .uleb128 0x19 # (DW_FORM_flag_present) .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .uleb128 0x11 # (DW_AT_low_pc) .uleb128 0x1 # (DW_FORM_addr) .uleb128 0x12 # (DW_AT_high_pc) .uleb128 0x6 # (DW_FORM_data4) .uleb128 0x40 # (DW_AT_frame_base) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x2116 # (DW_AT_GNU_all_tail_call_sites) .uleb128 0x19 # (DW_FORM_flag_present) .uleb128 0x1 # (DW_AT_sibling) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .uleb128 0x5 # (abbrev code) .uleb128 0x5 # (TAG: DW_TAG_formal_parameter) .byte 0 # DW_children_no .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .uleb128 0x2 # (DW_AT_location) .uleb128 0x18 # (DW_FORM_exprloc) .byte 0 .byte 0 .uleb128 0x6 # (abbrev code) .uleb128 0xf # (TAG: DW_TAG_pointer_type) .byte 0 # DW_children_no .uleb128 0xb # (DW_AT_byte_size) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .uleb128 0x7 # (abbrev code) .uleb128 0x2e # (TAG: DW_TAG_subprogram) .byte 0x1 # DW_children_yes .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x6a # (DW_AT_main_subprogram) .uleb128 0x19 # (DW_FORM_flag_present) .uleb128 0x36 # (DW_AT_calling_convention) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x11 # (DW_AT_low_pc) .uleb128 0x1 # (DW_FORM_addr) .uleb128 0x12 # (DW_AT_high_pc) .uleb128 0x6 # (DW_FORM_data4) .uleb128 0x40 # (DW_AT_frame_base) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x2116 # (DW_AT_GNU_all_tail_call_sites) .uleb128 0x19 # (DW_FORM_flag_present) .uleb128 0x1 # (DW_AT_sibling) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .uleb128 0x8 # (abbrev code) .uleb128 0x34 # (TAG: DW_TAG_variable) .byte 0 # DW_children_no .uleb128 0x3 # (DW_AT_name) .uleb128 0x8 # (DW_FORM_string) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .uleb128 0x9 # (abbrev code) .uleb128 0x34 # (TAG: DW_TAG_variable) .byte 0 # DW_children_no .uleb128 0x3 # (DW_AT_name) .uleb128 0xe # (DW_FORM_strp) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .uleb128 0x2 # (DW_AT_location) .uleb128 0x18 # (DW_FORM_exprloc) .byte 0 .byte 0 .uleb128 0xa # (abbrev code) .uleb128 0x34 # (TAG: DW_TAG_variable) .byte 0 # DW_children_no .uleb128 0x3 # (DW_AT_name) .uleb128 0x8 # (DW_FORM_string) .uleb128 0x3a # (DW_AT_decl_file) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x3b # (DW_AT_decl_line) .uleb128 0xb # (DW_FORM_data1) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .uleb128 0x2 # (DW_AT_location) .uleb128 0x18 # (DW_FORM_exprloc) .byte 0 .byte 0 .uleb128 0xb # (abbrev code) .uleb128 0xb # (TAG: DW_TAG_lexical_block) .byte 0x1 # DW_children_yes .uleb128 0x11 # (DW_AT_low_pc) .uleb128 0x1 # (DW_FORM_addr) .uleb128 0x12 # (DW_AT_high_pc) .uleb128 0x6 # (DW_FORM_data4) .byte 0 .byte 0 .uleb128 0xc # (abbrev code) .uleb128 0xb # (TAG: DW_TAG_lexical_block) .byte 0x1 # DW_children_yes .uleb128 0x11 # (DW_AT_low_pc) .uleb128 0x1 # (DW_FORM_addr) .uleb128 0x12 # (DW_AT_high_pc) .uleb128 0x6 # (DW_FORM_data4) .uleb128 0x1 # (DW_AT_sibling) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .uleb128 0xd # (abbrev code) .uleb128 0xb # (TAG: DW_TAG_lexical_block) .byte 0 # DW_children_no .uleb128 0x11 # (DW_AT_low_pc) .uleb128 0x1 # (DW_FORM_addr) .uleb128 0x12 # (DW_AT_high_pc) .uleb128 0x6 # (DW_FORM_data4) .byte 0 .byte 0 .uleb128 0xe # (abbrev code) .uleb128 0x1 # (TAG: DW_TAG_array_type) .byte 0x1 # DW_children_yes .uleb128 0x50 # (DW_AT_data_location) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x4f # (DW_AT_associated) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .uleb128 0x1 # (DW_AT_sibling) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .uleb128 0xf # (abbrev code) .uleb128 0x21 # (TAG: DW_TAG_subrange_type) .byte 0 # DW_children_no .uleb128 0x22 # (DW_AT_lower_bound) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x2f # (DW_AT_upper_bound) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x51 # (DW_AT_byte_stride) .uleb128 0x18 # (DW_FORM_exprloc) .byte 0 .byte 0 .uleb128 0x10 # (abbrev code) .uleb128 0x1 # (TAG: DW_TAG_array_type) .byte 0x1 # DW_children_yes .uleb128 0x50 # (DW_AT_data_location) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x4e # (DW_AT_allocated) .uleb128 0x18 # (DW_FORM_exprloc) .uleb128 0x49 # (DW_AT_type) .uleb128 0x13 # (DW_FORM_ref4) .byte 0 .byte 0 .byte 0 .section .debug_aranges,"",@progbits .long 0x1c # Length of Address Ranges Info .value 0x2 # DWARF Version .long .Ldebug_info0 # Offset of Compilation Unit Info .byte 0x4 # Size of Address .byte 0 # Size of Segment Descriptor .value 0 # Pad to 8 byte boundary .value 0 .long .Ltext0 # Address .long .Letext0-.Ltext0 # Length .long 0 .long 0 .section .debug_line,"",@progbits .Ldebug_line0: .section .debug_str,"MS",@progbits,1 .LASF7: .string "/home/jkratoch/redhat/gdb-clean/gdb/testsuite" .LASF3: .string "character(kind=1)" .LASF0: .string "argc" .LASF9: .string "vla_stride" .LASF2: .string "integer(kind=4)" .LASF5: .string "GNU Fortran2008 6.1.1 20160621 (Red Hat 6.1.1-3) -m32 -mtune=generic -march=i686 -g -fintrinsic-modules-path /usr/lib/gcc/x86_64-redhat-linux/6.1.1/32/finclude" .LASF8: .string "main" .LASF4: .string "pvla" .LASF6: .string "gdb.fortran/vla-stride.f90" .LASF1: .string "argv" .ident "GCC: (GNU) 6.1.1 20160621 (Red Hat 6.1.1-3)" .section .note.GNU-stack,"",@progbits ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-25 17:06 ` Jan Kratochvil @ 2016-08-25 17:22 ` Jan Kratochvil 2016-08-26 7:17 ` Jan Kratochvil 2016-09-02 13:44 ` Bernhard Heckel 1 sibling, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2016-08-25 17:22 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches On Thu, 25 Aug 2016 19:06:26 +0200, Jan Kratochvil wrote: > I have attached a fix. That fix has a regression for normal (64-bit) inferiors. I see the source handles negative stide specially. Particularly the comment here does not explain the code it comments: /* Adjust the data location with the value of byte stride if set, which can describe the separation between successive elements along the dimension. */ if (TYPE_BYTE_STRIDE (range_type) < 0) value += (TYPE_HIGH_BOUND (range_type) - TYPE_LOW_BOUND (range_type)) * TYPE_BYTE_STRIDE (range_type); else if (elt_stride < 0) { int offs = (elt_offs + 1) * elt_stride; elt_offs = TYPE_LENGTH (array_type) + offs; } But I do not negative stride values described in DWARF-4 anyhow. When it is used? With this interpretation of stride the gfortran random(?) stride value for arrays with single row would be really wrong. But I do not see a definition of negative stride in DWARF. Thanks, Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-25 17:22 ` Jan Kratochvil @ 2016-08-26 7:17 ` Jan Kratochvil 2016-09-01 10:11 ` Bernhard Heckel 0 siblings, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2016-08-26 7:17 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches [-- Attachment #1: Type: text/plain, Size: 344 bytes --] On Thu, 25 Aug 2016 19:22:17 +0200, Jan Kratochvil wrote: > I see the source handles negative stide specially. Particularly the comment > here does not explain the code it comments: With the attached patch disabling these cases still the supplied gdb.fortran/static-arrays.exp and gdb.fortran/vla-stride.exp PASS (on Fedora 24 x86_64). Jan [-- Attachment #2: 1 --] [-- Type: text/plain, Size: 1222 bytes --] diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c index 88801ac..695825a 100644 --- a/gdb/gdbtypes.c +++ b/gdb/gdbtypes.c @@ -2197,12 +2197,14 @@ resolve_dynamic_type_internal (struct type *type, { struct type *range_type = TYPE_INDEX_TYPE (resolved_type); +#if 0 /* Adjust the data location with the value of byte stride if set, which can describe the separation between successive elements along the dimension. */ if (TYPE_BYTE_STRIDE (range_type) < 0) value += (TYPE_HIGH_BOUND (range_type) - TYPE_LOW_BOUND (range_type)) * TYPE_BYTE_STRIDE (range_type); +#endif TYPE_DATA_LOCATION_ADDR (resolved_type) = value; TYPE_DATA_LOCATION_KIND (resolved_type) = PROP_CONST; diff --git a/gdb/valarith.c b/gdb/valarith.c index 9093969..eca7992 100644 --- a/gdb/valarith.c +++ b/gdb/valarith.c @@ -199,12 +199,14 @@ value_subscripted_rvalue (struct value *array, LONGEST index, int lowerbound) if (elt_stride > 0) elt_offs *= elt_stride; +#if 0 else if (elt_stride < 0) { int offs = (elt_offs + 1) * elt_stride; elt_offs = TYPE_LENGTH (array_type) + offs; } +#endif else elt_offs *= elt_size; ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-26 7:17 ` Jan Kratochvil @ 2016-09-01 10:11 ` Bernhard Heckel 0 siblings, 0 replies; 26+ messages in thread From: Bernhard Heckel @ 2016-09-01 10:11 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches On 26/08/2016 09:17, Jan Kratochvil wrote: > On Thu, 25 Aug 2016 19:22:17 +0200, Jan Kratochvil wrote: >> I see the source handles negative stide specially. Particularly the comment >> here does not explain the code it comments: > With the attached patch disabling these cases still the supplied > gdb.fortran/static-arrays.exp and gdb.fortran/vla-stride.exp PASS (on Fedora 24 > x86_64). > > > Jan Hi Jan, I am just setting up a Fedora24 environment. I will look into this stride issue and update the branch with your current findings. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-25 17:06 ` Jan Kratochvil 2016-08-25 17:22 ` Jan Kratochvil @ 2016-09-02 13:44 ` Bernhard Heckel 2016-09-04 17:15 ` Jan Kratochvil 1 sibling, 1 reply; 26+ messages in thread From: Bernhard Heckel @ 2016-09-02 13:44 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches On 25/08/2016 19:06, Jan Kratochvil wrote: > On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote: >> created a branch with all stride patches. > users/bheckel/fortran-strides > 2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b > >> I don't see regression on RH7.1, gcc 4.8.3-9 > I see a regression for 32-bit targets (x86_64-m32 or native i686) > on Fedora 24 (gcc-gfortran-6.1.1-3.fc24.x86_64). I do not see the regression > on CentOS-7.2 (x86_64-m32). > > print pvla^M > value requires 4294967288 bytes, which is more than max-value-size^M > (gdb) FAIL: gdb.fortran/vla-stride.exp: print single-element > > I have attached a fix. > > It is because: > <115> DW_AT_lower_bound : 4 byte block: 97 23 10 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 16; DW_OP_deref) > <11a> DW_AT_upper_bound : 4 byte block: 97 23 14 6 (DW_OP_push_object_address; DW_OP_plus_uconst: 20; DW_OP_deref) > <11f> DW_AT_byte_stride : 6 byte block: 97 23 c 6 34 1e (DW_OP_push_object_address; DW_OP_plus_uconst: 12; DW_OP_deref; DW_OP_lit4; DW_OP_mul) > DW_AT_lower_bound == 1 > DW_AT_upper_bound == 1 > DW_AT_byte_stride == (-2) * 4 == -8 > > I am not sure if gfortran is really wrong or not but a stride does not make > sense for me for a single row array. > > Attaching also gdb.fortran/vla-stride.f90 from your branch built with > gcc-gfortran-6.1.1-3.fc24.x86_64 on Fedora 24 x86_64 in -m32 mode. > > Besides that I see on all archs > -FAIL: gdb.pascal/arrays.exp: Print dynamic array of string > +FAIL: gdb.pascal/arrays.exp: Print dynamic array of string (GDB internal error) > but that testcase is only in Fedora and the Pascal (fpc) support has been not > well maintained so far so I am OK with that. > > > Thanks, > Jan Hi Jan, found the root cause of the issue on 32bit inferior. According to DWARF4 (Page 100) strides can be negative but evaluation of dynamic properties in GDB is done via CORE_ADDR which is unsigned. This causes the issue that the type length seems to be way to big. The following code is not claimed to be a fix, just want to point you to the right direction. In gdbtypes.c: prop = &TYPE_RANGE_DATA (dyn_range_type)->stride; if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value)) { /* if target is 32bit, execute next if clause */ if (value > (2^31)) value += 2^32; stride.kind = PROP_CONST; stride.data.const_val = value; } Also, in dwarf2read.c all DW_AT_...STRIDE 's are handles as unsigned. This has to be fixed as well. I will investigate more on the stride topic next week. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-09-02 13:44 ` Bernhard Heckel @ 2016-09-04 17:15 ` Jan Kratochvil 2016-09-07 10:29 ` Bernhard Heckel 2016-09-07 20:24 ` Jan Kratochvil 0 siblings, 2 replies; 26+ messages in thread From: Jan Kratochvil @ 2016-09-04 17:15 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches [-- Attachment #1: Type: text/plain, Size: 878 bytes --] On Fri, 02 Sep 2016 15:44:15 +0200, Bernhard Heckel wrote: > dynamic properties in GDB is done via CORE_ADDR which is unsigned. > This causes the issue that the type length seems to be way to big. Maybe that explains also a regression visible only on i686 (32-bit host). It still PASSes on x86_64 (64-bit host) with either native od 32-bit inferior (-m32): The length is bogus (it is %rax or %eax) but it should be some number. i686: ptype reg_string^M type = char [variable length]^M ^^^^^^^^^^^^^^^ (gdb) FAIL: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string p reg_string^M Insufficient memory in host GDB for object of size 4160138653 bytes, maximum allowed 536870911 bytes.^M x86_64 or x86_64 -m32: ptype reg_string^M type = char [4160048541]^M (gdb) PASS: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string Attaching the Fedora testcase. Thanks, Jan [-- Attachment #2: dw2-bound-loclist.patch --] [-- Type: text/plain, Size: 10906 bytes --] --- /dev/null 2016-08-23 22:46:08.455975850 +0200 +++ gdb-7.11.90.20160904/gdb/testsuite/gdb.dwarf2/dw2-bound-loclist.exp 2016-09-04 19:09:23.719880045 +0200 @@ -0,0 +1,66 @@ +# Copyright 2010 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Test printing variable with dynamic bounds which reference a different +# (artificial in the GCC case) variable containing loclist as its location. +# This testcase uses value (not address) of the referenced variable: +# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43762 + +# This test can only be run on targets which support DWARF-2 and use gas. +# For now pick a sampling of likely targets. +if {![istarget *-*-linux*] + && ![istarget *-*-gnu*] + && ![istarget *-*-elf*] + && ![istarget *-*-openbsd*] + && ![istarget arm-*-eabi*] + && ![istarget powerpc-*-eabi*]} { + return 0 +} + +set testfile dw2-bound-loclist +if { [prepare_for_testing ${testfile}.exp ${testfile} [list ${testfile}.S main.c] {}] } { + return -1 +} + +# Verify it behaves at least as an unbound array without inferior. + +# FIXME: FSF GDB crashes due to !has_stack_frames (). +# But in practice that should not happen. +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43762 +#set test "p a_string" +#gdb_test_multiple $test $test { +# -re " = 0x\[0-9a-f\]+ \"seennotseen\"\r\n$gdb_prompt $" { +# pass $test +# } +# -re "No registers\\.\r\n$gdb_prompt $" { +# kfail "vlaregression" $test +# } +#} +# +#gdb_test "ptype a_string" {type = char \[variable length\]} + +# Not runto_main as dw2-bound-loclist.S handles only the first byte of main. +if ![runto "*main"] { + return -1 +} + +gdb_test "p a_string" { = "seen"} +gdb_test "ptype a_string" {type = char \[4\]} + +gdb_test "p b_string" { = (0x[0-9a-f]+ )?"seennotseen"} +gdb_test "ptype b_string" {type = char \[\]} + +# The register contains unpredictable value - the array size. +gdb_test "ptype reg_string" {type = char \[-?[0-9]+\]} --- /dev/null 2016-08-23 22:46:08.455975850 +0200 +++ gdb-7.11.90.20160904/gdb/testsuite/gdb.dwarf2/dw2-bound-loclist.S 2016-09-04 19:09:23.719880045 +0200 @@ -0,0 +1,246 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2010 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. */ + +/* Debug information */ + +/* We will `break *main' at the very first instruction. */ +#define main_length 1 + + .section .data +vardata: + /* See DW_OP_lit3 + 1 (0-based). */ + .string "seennotseen" + + .section .debug_info +.Lcu1_begin: + .4byte .Lcu1_end - .Lcu1_start /* Length of Compilation Unit */ +.Lcu1_start: + .2byte 2 /* DWARF version number */ + .4byte .Ldebug_abbrev0 /* Offset Into Abbrev. Section */ + .byte 4 /* Pointer Size (in bytes) */ + + /* CU die */ + .uleb128 1 /* Abbrev: DW_TAG_compile_unit */ + .4byte .Lproducer /* DW_AT_producer */ + /* Use C++ to exploit a bug in parsing DW_AT_name "". */ + .byte 4 /* DW_AT_language (C++) - */ + .4byte main /* DW_AT_low_pc */ + .byte main_length /* DW_AT_high_pc */ + +.Larray_type: + .uleb128 2 /* Abbrev: DW_TAG_array_type */ + .4byte .Lchar_type-.Lcu1_begin /* DW_AT_type */ + + .uleb128 3 /* Abbrev: DW_TAG_subrange_type */ + .4byte .Luint_type-.Lcu1_begin /* DW_AT_type */ + .byte 0 /* DW_AT_lower_bound */ + .4byte .Llen_var-.Lcu1_begin /* DW_AT_upper_bound */ + .byte 0 /* End of children of die */ + + /* DW_AT_upper_bound is referencing an optimized-out variable. */ +.Larrayb_type: + .uleb128 2 /* Abbrev: DW_TAG_array_type */ + .4byte .Lchar_type-.Lcu1_begin /* DW_AT_type */ + + .uleb128 3 /* Abbrev: DW_TAG_subrange_type */ + .4byte .Luint_type-.Lcu1_begin /* DW_AT_type */ + .byte 0 /* DW_AT_lower_bound */ + .4byte .Llenb_var-.Lcu1_begin /* DW_AT_upper_bound */ + .byte 0 /* End of children of die */ + + /* DW_AT_upper_bound is referencing register. */ +.Larrayreg_type: + .uleb128 2 /* Abbrev: DW_TAG_array_type */ + .4byte .Lchar_type-.Lcu1_begin /* DW_AT_type */ + + .uleb128 8 /* Abbrev: DW_TAG_subrange_type with block */ + .4byte .Luint_type-.Lcu1_begin /* DW_AT_type */ + .byte 0 /* DW_AT_lower_bound */ + .byte 2f - 1f /* DW_AT_upper_bound */ +1: .byte 0x50 /* DW_OP_reg0 */ +2: + .byte 0 /* End of children of die */ + +.Luint_type: + .uleb128 4 /* Abbrev: DW_TAG_base_type */ + .4byte .Luint_str /* DW_AT_name */ + .byte 4 /* DW_AT_byte_size */ + .byte 7 /* DW_AT_encoding */ + +.Lchar_type: + .uleb128 4 /* Abbrev: DW_TAG_base_type */ + .4byte .Lchar_str /* DW_AT_name */ + .byte 1 /* DW_AT_byte_size */ + .byte 6 /* DW_AT_encoding */ + +.Llen_var: + .uleb128 5 /* Abbrev: DW_TAG_variable artificial */ + .byte 1 /* DW_AT_artificial */ + .4byte .Luint_type-.Lcu1_begin /* DW_AT_type */ + .4byte .Llen_loclist-.Lloclist /* DW_AT_location */ + + /* optimized-out variable for b_string. */ +.Llenb_var: + .uleb128 7 /* Abbrev: DW_TAG_variable artificial no DW_AT_location */ + .byte 1 /* DW_AT_artificial */ + .4byte .Luint_type-.Lcu1_begin /* DW_AT_type */ + + .uleb128 6 /* Abbrev: DW_TAG_variable DW_FORM_string */ + .string "a_string" /* DW_AT_name */ + .4byte .Larray_type-.Lcu1_begin /* DW_AT_type */ + .byte 2f - 1f /* DW_AT_location */ +1: .byte 3 /* DW_OP_addr */ + .4byte vardata /* <addr> */ +2: + + /* DW_AT_upper_bound is referencing an optimized-out variable. */ + .uleb128 6 /* Abbrev: DW_TAG_variable DW_FORM_string */ + .string "b_string" /* DW_AT_name */ + .4byte .Larrayb_type-.Lcu1_begin /* DW_AT_type */ + .byte 2f - 1f /* DW_AT_location */ +1: .byte 3 /* DW_OP_addr */ + .4byte vardata /* <addr> */ +2: + + /* DW_AT_upper_bound is referencing register. */ + .uleb128 6 /* Abbrev: DW_TAG_variable DW_FORM_string */ + .string "reg_string" /* DW_AT_name */ + .4byte .Larrayreg_type-.Lcu1_begin /* DW_AT_type */ + .byte 2f - 1f /* DW_AT_location */ +1: .byte 3 /* DW_OP_addr */ + .4byte vardata /* <addr> */ +2: + + .byte 0 /* End of children of CU */ +.Lcu1_end: + + .section .debug_loc +.Lloclist: +.Llen_loclist: + .4byte 0 # Location list begin address + .4byte main_length # Location list end address + .value 2f-1f # Location expression size +1: .byte 0x33 # DW_OP_lit3 + .byte 0x9f # DW_OP_stack_value +2: + .quad 0x0 # Location list terminator begin (*.LLST2) + .quad 0x0 # Location list terminator end (*.LLST2) + + .section .debug_abbrev +.Ldebug_abbrev0: + .uleb128 1 /* Abbrev code */ + .uleb128 0x11 /* DW_TAG_compile_unit */ + .byte 0x1 /* has_children */ + .uleb128 0x25 /* DW_AT_producer */ + .uleb128 0xe /* DW_FORM_strp */ + .uleb128 0x13 /* DW_AT_language */ + .uleb128 0xb /* DW_FORM_data1 */ + .uleb128 0x11 /* DW_AT_low_pc */ + .uleb128 0x1 /* DW_FORM_addr */ + .uleb128 0x12 /* DW_AT_high_pc */ + .uleb128 0xb /* DW_FORM_data1 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .uleb128 2 /* Abbrev code */ + .uleb128 0x1 /* TAG: DW_TAG_array_type */ + .byte 0x1 /* DW_children_yes */ + .uleb128 0x49 /* DW_AT_type */ + .uleb128 0x13 /* DW_FORM_ref4 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .uleb128 3 /* Abbrev code */ + .uleb128 0x21 /* DW_TAG_subrange_type */ + .byte 0x0 /* no children */ + .uleb128 0x49 /* DW_AT_type */ + .uleb128 0x13 /* DW_FORM_ref4 */ + .uleb128 0x22 /* DW_AT_lower_bound */ + .uleb128 0xb /* DW_FORM_data1 */ + .uleb128 0x2f /* DW_AT_upper_bound */ + .uleb128 0x13 /* DW_FORM_ref4 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .uleb128 4 /* Abbrev code */ + .uleb128 0x24 /* DW_TAG_base_type */ + .byte 0x0 /* no_children */ + .uleb128 0x3 /* DW_AT_name */ + .uleb128 0xe /* DW_FORM_strp */ + .uleb128 0xb /* DW_AT_byte_size */ + .uleb128 0xb /* DW_FORM_data1 */ + .uleb128 0x3e /* DW_AT_encoding */ + .uleb128 0xb /* DW_FORM_data1 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .uleb128 5 /* Abbrev code */ + .uleb128 0x34 /* DW_TAG_variable */ + .byte 0x0 /* no_children */ + .uleb128 0x34 /* DW_AT_artificial */ + .uleb128 0x0c /* DW_FORM_flag */ + .uleb128 0x49 /* DW_AT_type */ + .uleb128 0x13 /* DW_FORM_ref4 */ + .uleb128 0x02 /* DW_AT_location */ + .uleb128 0x06 /* DW_FORM_data4 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .uleb128 6 /* Abbrev code */ + .uleb128 0x34 /* DW_TAG_variable */ + .byte 0x0 /* no_children */ + .uleb128 0x3 /* DW_AT_name */ + .uleb128 0x8 /* DW_FORM_string */ + .uleb128 0x49 /* DW_AT_type */ + .uleb128 0x13 /* DW_FORM_ref4 */ + .uleb128 0x2 /* DW_AT_location */ + .uleb128 0xa /* DW_FORM_block1 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .uleb128 7 /* Abbrev code */ + .uleb128 0x34 /* DW_TAG_variable */ + .byte 0x0 /* no_children */ + .uleb128 0x34 /* DW_AT_artificial */ + .uleb128 0x0c /* DW_FORM_flag */ + .uleb128 0x49 /* DW_AT_type */ + .uleb128 0x13 /* DW_FORM_ref4 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .uleb128 8 /* Abbrev code */ + .uleb128 0x21 /* DW_TAG_subrange_type with block */ + .byte 0x0 /* no children */ + .uleb128 0x49 /* DW_AT_type */ + .uleb128 0x13 /* DW_FORM_ref4 */ + .uleb128 0x22 /* DW_AT_lower_bound */ + .uleb128 0xb /* DW_FORM_data1 */ + .uleb128 0x2f /* DW_AT_upper_bound */ + .uleb128 0xa /* DW_FORM_block1 */ + .byte 0x0 /* Terminator */ + .byte 0x0 /* Terminator */ + + .byte 0x0 /* Terminator */ + +/* String table */ + .section .debug_str +.Lproducer: + .string "GNU C 3.3.3" +.Lchar_str: + .string "char" +.Luint_str: + .string "unsigned int" ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-09-04 17:15 ` Jan Kratochvil @ 2016-09-07 10:29 ` Bernhard Heckel 2016-09-07 20:05 ` Jan Kratochvil 2016-09-12 21:05 ` Jan Kratochvil 2016-09-07 20:24 ` Jan Kratochvil 1 sibling, 2 replies; 26+ messages in thread From: Bernhard Heckel @ 2016-09-07 10:29 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches On 04/09/2016 19:14, Jan Kratochvil wrote: > On Fri, 02 Sep 2016 15:44:15 +0200, Bernhard Heckel wrote: >> dynamic properties in GDB is done via CORE_ADDR which is unsigned. >> This causes the issue that the type length seems to be way to big. > Maybe that explains also a regression visible only on i686 (32-bit host). > It still PASSes on x86_64 (64-bit host) with either native od 32-bit inferior > (-m32): > > The length is bogus (it is %rax or %eax) but it should be some number. > > i686: > ptype reg_string^M > type = char [variable length]^M > ^^^^^^^^^^^^^^^ > (gdb) FAIL: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string > p reg_string^M > Insufficient memory in host GDB for object of size 4160138653 bytes, maximum allowed 536870911 bytes.^M > > x86_64 or x86_64 -m32: > ptype reg_string^M > type = char [4160048541]^M > (gdb) PASS: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string > > Attaching the Fedora testcase. > > > Thanks, > Jan Hi Jan, I just recreated my two user branches. - Fixed should be "Werror indentation" on the vla-string branch - Stride issues you reported in general (stride branch) - Stride issues on 32bit appl. running on 64bit system (gdb) (stride branch) - Fixed also neg. bounds on 32bit appl. running on 64bit system (stride branch) Let me know your results for the two branches. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-09-07 10:29 ` Bernhard Heckel @ 2016-09-07 20:05 ` Jan Kratochvil 2016-09-12 21:05 ` Jan Kratochvil 1 sibling, 0 replies; 26+ messages in thread From: Jan Kratochvil @ 2016-09-07 20:05 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches On Wed, 07 Sep 2016 12:29:06 +0200, Bernhard Heckel wrote: > I just recreated my two user branches. users/bheckel/fortran-strides users/bheckel/fortran-vla-strings > - Fixed should be "Werror indentation" on the vla-string branch > - Stride issues you reported in general (stride branch) > - Stride issues on 32bit appl. running on 64bit system (gdb) (stride branch) > - Fixed also neg. bounds on 32bit appl. running on 64bit system (stride > branch) Yes, confirming the 32-bit strides issues seem to be fixed, thank you very much. FYI I still need to carry this "selected_frame" patch for Fortran backtraces: https://sourceware.org/ml/gdb-patches/2016-09/msg00011.html But I will need to reproduce it with FSF GDB sources first. Thanks, Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-09-07 10:29 ` Bernhard Heckel 2016-09-07 20:05 ` Jan Kratochvil @ 2016-09-12 21:05 ` Jan Kratochvil 2016-09-14 7:24 ` Bernhard Heckel 1 sibling, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2016-09-12 21:05 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches [-- Attachment #1: Type: text/plain, Size: 360 bytes --] On Wed, 07 Sep 2016 12:29:06 +0200, Bernhard Heckel wrote: > I just recreated my two user branches. I see a regression against former Intel VLA patchset for the attached testcase. gdb_test "p c40pt(2)" " = '1-hello.*" p c40pt(2)^M $2 = '\001\000\000\000\061-hello', ' ' <repeats 29 times>^M (gdb) FAIL: gdb.fortran/dwarf-stride.exp: p c40pt(2) Thanks, Jan [-- Attachment #2: 1 --] [-- Type: text/plain, Size: 3338 bytes --] diff --git a/gdb/testsuite/gdb.fortran/dwarf-stride.exp b/gdb/testsuite/gdb.fortran/dwarf-stride.exp new file mode 100644 index 0000000..d7b8bea --- /dev/null +++ b/gdb/testsuite/gdb.fortran/dwarf-stride.exp @@ -0,0 +1,42 @@ +# Copyright 2009 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +# This file was written by Jan Kratochvil <jan.kratochvil@redhat.com>. + +# This file is part of the gdb testsuite. Array element stride must not be +# specified in the number of elements but in a number of bytes instead. +# Original problem: +# (gdb) p c40pt(1) +# $1 = '0-hello', ' ' <repeats 33 times> +# (gdb) p c40pt(2) +# warning: Fortran array stride not divisible by the element size + +set testfile dwarf-stride +set srcfile ${testfile}.f90 + +if { [prepare_for_testing ${testfile}.exp ${testfile} ${srcfile} {debug f90}] } { + return -1 +} + +if ![runto MAIN__] then { + perror "couldn't run to breakpoint MAIN__" + continue +} + +gdb_breakpoint [gdb_get_line_number "break-here"] +gdb_continue_to_breakpoint "break-here" ".*break-here.*" +gdb_test "p c40pt(1)" " = '0-hello.*" +gdb_test "p c40pt(2)" " = '1-hello.*" diff --git a/gdb/testsuite/gdb.fortran/dwarf-stride.f90 b/gdb/testsuite/gdb.fortran/dwarf-stride.f90 new file mode 100644 index 0000000..e492b3a --- /dev/null +++ b/gdb/testsuite/gdb.fortran/dwarf-stride.f90 @@ -0,0 +1,40 @@ +! Copyright 2009 Free Software Foundation, Inc. +! +! This program is free software; you can redistribute it and/or modify +! it under the terms of the GNU General Public License as published by +! the Free Software Foundation; either version 2 of the License, or +! (at your option) any later version. +! +! This program is distributed in the hope that it will be useful, +! but WITHOUT ANY WARRANTY; without even the implied warranty of +! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +! GNU General Public License for more details. +! +! You should have received a copy of the GNU General Public License +! along with this program; if not, write to the Free Software +! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +! +! File written by Alan Matsuoka. + +program repro + + type small_stride + character*40 long_string + integer small_pad + end type small_stride + + type(small_stride), dimension (20), target :: unpleasant + character*40, pointer, dimension(:):: c40pt + + integer i + + do i = 0,19 + unpleasant(i+1)%small_pad = i+1 + unpleasant(i+1)%long_string = char (ichar('0') + i) // '-hello' + end do + + c40pt => unpleasant%long_string + + print *, c40pt ! break-here + +end program repro ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-09-12 21:05 ` Jan Kratochvil @ 2016-09-14 7:24 ` Bernhard Heckel 2016-09-14 12:53 ` Jan Kratochvil 0 siblings, 1 reply; 26+ messages in thread From: Bernhard Heckel @ 2016-09-14 7:24 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Weinmann, Christoph T, gdb-patches On 12/09/2016 23:04, Jan Kratochvil wrote: > On Wed, 07 Sep 2016 12:29:06 +0200, Bernhard Heckel wrote: >> I just recreated my two user branches. > I see a regression against former Intel VLA patchset for the attached testcase. > > gdb_test "p c40pt(2)" " = '1-hello.*" > p c40pt(2)^M > $2 = '\001\000\000\000\061-hello', ' ' <repeats 29 times>^M > (gdb) FAIL: gdb.fortran/dwarf-stride.exp: p c40pt(2) > > > Thanks, > Jan Hi Jan, I tested with GCC 4.8.3 and IFORT 17.0.0. Both passes. With Fedora24, GCC 6.1.1 I see the same results as you. Investigation is showing that GCC 6.1.1 doesn't provide the stride information (DWARF) which results in incorrect offsets. Are you going to file a bug for GCC? BTW: Nice testcase Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-09-14 7:24 ` Bernhard Heckel @ 2016-09-14 12:53 ` Jan Kratochvil 0 siblings, 0 replies; 26+ messages in thread From: Jan Kratochvil @ 2016-09-14 12:53 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches On Wed, 14 Sep 2016 09:24:15 +0200, Bernhard Heckel wrote: > With Fedora24, GCC 6.1.1 I see the same results as you. Investigation is > showing that > GCC 6.1.1 doesn't provide the stride information (DWARF) which results in > incorrect offsets. > > Are you going to file a bug for GCC? Thanks for the investigation, sorry I did not verify that myself. I have filed it as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589 Thanks, Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-09-04 17:15 ` Jan Kratochvil 2016-09-07 10:29 ` Bernhard Heckel @ 2016-09-07 20:24 ` Jan Kratochvil 1 sibling, 0 replies; 26+ messages in thread From: Jan Kratochvil @ 2016-09-07 20:24 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches On Sun, 04 Sep 2016 19:14:53 +0200, Jan Kratochvil wrote: > On Fri, 02 Sep 2016 15:44:15 +0200, Bernhard Heckel wrote: > > dynamic properties in GDB is done via CORE_ADDR which is unsigned. > > This causes the issue that the type length seems to be way to big. > > Maybe that explains also a regression visible only on i686 (32-bit host). > It still PASSes on x86_64 (64-bit host) with either native od 32-bit inferior > (-m32): > > The length is bogus (it is %rax or %eax) but it should be some number. > > i686: > ptype reg_string^M > type = char [variable length]^M > ^^^^^^^^^^^^^^^ > (gdb) FAIL: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string > p reg_string^M > Insufficient memory in host GDB for object of size 4160138653 bytes, maximum allowed 536870911 bytes.^M > > x86_64 or x86_64 -m32: > ptype reg_string^M > type = char [4160048541]^M > (gdb) PASS: gdb.dwarf2/dw2-bound-loclist.exp: ptype reg_string Confirming also this specific issue got fixed today, great! Thanks, Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-08-23 13:34 ` Bernhard Heckel 2016-08-25 17:06 ` Jan Kratochvil @ 2016-09-01 9:48 ` Jan Kratochvil 1 sibling, 0 replies; 26+ messages in thread From: Jan Kratochvil @ 2016-09-01 9:48 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Weinmann, Christoph T, gdb-patches [-- Attachment #1: Type: text/plain, Size: 522 bytes --] On Tue, 23 Aug 2016 15:34:09 +0200, Bernhard Heckel wrote: > created a branch with all stride patches. users/bheckel/fortran-strides 2c392d41a3f2e38deeb9db5b7a93ca45682bbe3b > I don't see regression on RH7.1, gcc 4.8.3-9 I see a regression in Fedora-specific testcase, attaching it also with a fix. Although it does not work just on your branch, apparently it has some dependency on other Fedora patches. http://pkgs.fedoraproject.org/cgit/rpms/gdb.git/tree/ It can be resolved later for upstream GDB I guess. Jan [-- Attachment #2: gdb-vla-intel-stringbt-fix.patch --] [-- Type: text/plain, Size: 6873 bytes --] http://sourceware.org/ml/gdb-patches/2014-08/msg00025.html Subject: [patch 1/2] Re: Crash regression(?) printing Fortran strings in bt [Re: [V2 00/23] Fortran dynamic array support] --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, 01 Aug 2014 09:20:19 +0200, Keven Boell wrote: > I just tried it on Fedora 20 i686. Applied the patch, you mentioned, on top of > the Fortran VLA series and executed your dynamic-other-frame test. Everything > is working fine here, I cannot reproduce the crash. I have it reproducible on Fedora 20 i686 with plain CFLAGS=-g ./configure;make;cd gdb/testsuite;make site.exp;runtest gdb.fortran/dynamic-other-frame.exp Besides that I have updated the testcase with gdb_test_no_output "set print frame-arguments all" so that there is no longer needed the patch: [patch] Display Fortran strings in backtraces https://sourceware.org/ml/gdb-patches/2014-07/msg00709.html The fix below has no regressions for me. Unfortunately I do not see why you cannot reproduce it. Thanks, Jan --- ./gdb/dwarf2loc.c 2016-08-29 04:01:25.000000000 +0200 +++ ./gdb/dwarf2loc.c 2016-09-01 11:00:20.258909494 +0200 @@ -2289,6 +2289,15 @@ const struct dwarf_expr_context_funcs dw dwarf_expr_get_obj_addr }; +static void +select_frame_cleanup (void *arg) +{ + struct frame_info *frame = (struct frame_info *) arg; + + if (frame != NULL) + select_frame (frame); +} + /* Evaluate a location description, starting at DATA and with length SIZE, to find the current location of variable of TYPE in the context of FRAME. BYTE_OFFSET is applied after the contents are @@ -2318,6 +2327,11 @@ dwarf2_evaluate_loc_desc_full (struct ty ctx = new_dwarf_expr_context (); old_chain = make_cleanup_free_dwarf_expr_context (ctx); + + make_cleanup (select_frame_cleanup, deprecated_safe_get_selected_frame ()); + if (frame != NULL) + select_frame (frame); + value_chain = make_cleanup_value_free_to_mark (value_mark ()); ctx->gdbarch = get_objfile_arch (objfile); Index: gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame-stub.f90 =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame-stub.f90 2015-05-31 16:14:05.844545344 +0200 @@ -0,0 +1,24 @@ +! Copyright 2010 Free Software Foundation, Inc. +! +! This program is free software; you can redistribute it and/or modify +! it under the terms of the GNU General Public License as published by +! the Free Software Foundation; either version 2 of the License, or +! (at your option) any later version. +! +! This program is distributed in the hope that it will be useful, +! but WITHOUT ANY WARRANTY; without even the implied warranty of +! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +! GNU General Public License for more details. +! +! You should have received a copy of the GNU General Public License +! along with this program; if not, write to the Free Software +! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +! +! Ihis file is the Fortran source file for dynamic.exp. +! Original file written by Jakub Jelinek <jakub@redhat.com>. +! Modified for the GDB testcase by Jan Kratochvil <jan.kratochvil@redhat.com>. + +subroutine bar + real :: dummy + dummy = 1 +end subroutine bar Index: gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.exp =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.exp 2015-05-31 16:14:05.845545351 +0200 @@ -0,0 +1,39 @@ +# Copyright 2010 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +set testfile "dynamic-other-frame" +set srcfile1 ${testfile}.f90 +set srcfile2 ${testfile}-stub.f90 +set objfile2 [standard_output_file ${testfile}-stub.o] +set executable ${testfile} +set binfile [standard_output_file ${executable}] + +if { [gdb_compile "${srcdir}/${subdir}/${srcfile2}" "${objfile2}" object {f90}] != "" + || [gdb_compile "${srcdir}/${subdir}/${srcfile1} ${objfile2}" "${binfile}" executable {debug f90}] != "" } { + untested "Couldn't compile ${srcfile1} or ${srcfile2}" + return -1 +} + +clean_restart ${executable} + +gdb_test_no_output "set print frame-arguments all" + +if ![runto bar_] then { + perror "couldn't run to bar_" + continue +} + +gdb_test "bt" {foo \(string='hello'.*} Index: gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.f90 =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ gdb-7.9.50.20150520/gdb/testsuite/gdb.fortran/dynamic-other-frame.f90 2015-05-31 16:14:05.845545351 +0200 @@ -0,0 +1,36 @@ +! Copyright 2010 Free Software Foundation, Inc. +! +! This program is free software; you can redistribute it and/or modify +! it under the terms of the GNU General Public License as published by +! the Free Software Foundation; either version 2 of the License, or +! (at your option) any later version. +! +! This program is distributed in the hope that it will be useful, +! but WITHOUT ANY WARRANTY; without even the implied warranty of +! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +! GNU General Public License for more details. +! +! You should have received a copy of the GNU General Public License +! along with this program; if not, write to the Free Software +! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +! +! Ihis file is the Fortran source file for dynamic.exp. +! Original file written by Jakub Jelinek <jakub@redhat.com>. +! Modified for the GDB testcase by Jan Kratochvil <jan.kratochvil@redhat.com>. + +subroutine foo (string) + interface + subroutine bar + end subroutine + end interface + character string*(*) + call bar ! stop-here +end subroutine foo +program test + interface + subroutine foo (string) + character string*(*) + end subroutine + end interface + call foo ('hello') +end ^ permalink raw reply [flat|nested] 26+ messages in thread
* [V4 00/21] Fortran dynamic array support
@ 2015-01-14 13:49 Keven Boell
2015-05-28 20:36 ` Jan Kratochvil
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Keven Boell @ 2015-01-14 13:49 UTC (permalink / raw)
To: gdb-patches; +Cc: Keven Boell
This patch series add Fortran dynamic array support to gdb.
It allows the user to evaluate a dynamic array like an ordinary static array
e.g. print its elements instead of printing the pointer to the array.
In addition the size of a dynamic array can be retrieved with gdbs builtin
sizeof operator. Furthermore this series add support for Fortran stride support.
1| integer, allocatable :: ary(:)
2| allocate(ary(5))
3| ary(:) = 42
(gdb) print ary
$1 = (42, 42, 42, 42, 42)
(gdb) print sizeof (ary)
$2 = 20
(gdb) ptype ary
type = integer(kind=4) (5)
This series is a follow up for the following C99 variable length array
support series:
https://sourceware.org/ml/gdb-patches/2013-12/msg00625.html
Patch series V4 restructures the patches into more logical parts. Tests
were added directly to the functional changes, instead of the main dynamic
array tests to avoid one huge patch.
Keven Boell (18):
vla: introduce allocated/associated flags
vla: make dynamic fortran arrays functional.
test: basic tests for dynamic array evaluations in Fortran.
test: evaluate dynamic arrays using Fortran primitives.
test: dynamic arrays passed to subroutines.
test: correct ptype of dynamic arrays in Fortran.
test: evaluating allocation/association status
test: dynamic arrays passed to functions.
test: accessing dynamic array history values.
test: basic MI test for the dynamic array support.
test: test sizeof for dynamic fortran arrays.
test: add archer dynamic other frame test
vla: reconstruct value to compute bounds of target type
vla: use value constructor instead of raw-buffer manipulation
vla: get dynamic array corner cases to work
vla: Fortran dynamic string support
vla: add stride support to fortran arrays.
vla: add NEWS entry for dynamic array support
gdb/NEWS | 3 +
gdb/c-valprint.c | 11 +-
gdb/dwarf2loc.c | 16 ++
gdb/dwarf2loc.h | 6 +
gdb/dwarf2read.c | 181 +++++++++++++++++--
gdb/f-typeprint.c | 68 +++++---
gdb/f-valprint.c | 124 +++++--------
gdb/gdbtypes.c | 167 ++++++++++++++++--
gdb/gdbtypes.h | 43 +++++
.../gdb.fortran/dynamic-other-frame-stub.f90 | 24 +++
gdb/testsuite/gdb.fortran/dynamic-other-frame.exp | 39 +++++
gdb/testsuite/gdb.fortran/dynamic-other-frame.f90 | 36 ++++
gdb/testsuite/gdb.fortran/vla-alloc-assoc.exp | 65 +++++++
gdb/testsuite/gdb.fortran/vla-datatypes.exp | 82 +++++++++
gdb/testsuite/gdb.fortran/vla-datatypes.f90 | 51 ++++++
gdb/testsuite/gdb.fortran/vla-func.exp | 61 +++++++
gdb/testsuite/gdb.fortran/vla-func.f90 | 71 ++++++++
gdb/testsuite/gdb.fortran/vla-history.exp | 62 +++++++
gdb/testsuite/gdb.fortran/vla-ptr-info.exp | 32 ++++
gdb/testsuite/gdb.fortran/vla-ptype-sub.exp | 87 ++++++++++
gdb/testsuite/gdb.fortran/vla-ptype.exp | 96 +++++++++++
gdb/testsuite/gdb.fortran/vla-sizeof.exp | 46 +++++
gdb/testsuite/gdb.fortran/vla-stride.exp | 44 +++++
gdb/testsuite/gdb.fortran/vla-stride.f90 | 30 ++++
gdb/testsuite/gdb.fortran/vla-strings.exp | 104 +++++++++++
gdb/testsuite/gdb.fortran/vla-strings.f90 | 40 +++++
gdb/testsuite/gdb.fortran/vla-sub.f90 | 82 +++++++++
.../gdb.fortran/vla-value-sub-arbitrary.exp | 35 ++++
gdb/testsuite/gdb.fortran/vla-value-sub-finish.exp | 49 ++++++
gdb/testsuite/gdb.fortran/vla-value-sub.exp | 90 ++++++++++
gdb/testsuite/gdb.fortran/vla-value.exp | 148 ++++++++++++++++
gdb/testsuite/gdb.fortran/vla.f90 | 56 ++++++
gdb/testsuite/gdb.mi/mi-vla-fortran.exp | 182 ++++++++++++++++++++
gdb/testsuite/gdb.mi/vla.f90 | 42 +++++
gdb/typeprint.c | 7 +
gdb/valarith.c | 23 ++-
gdb/valprint.c | 40 +++++
gdb/valprint.h | 4 +
gdb/value.c | 23 ++-
39 files changed, 2231 insertions(+), 139 deletions(-)
create mode 100644 gdb/testsuite/gdb.fortran/dynamic-other-frame-stub.f90
create mode 100644 gdb/testsuite/gdb.fortran/dynamic-other-frame.exp
create mode 100644 gdb/testsuite/gdb.fortran/dynamic-other-frame.f90
create mode 100644 gdb/testsuite/gdb.fortran/vla-alloc-assoc.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-datatypes.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-datatypes.f90
create mode 100644 gdb/testsuite/gdb.fortran/vla-func.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-func.f90
create mode 100644 gdb/testsuite/gdb.fortran/vla-history.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-ptr-info.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-ptype-sub.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-ptype.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-sizeof.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-stride.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-stride.f90
create mode 100644 gdb/testsuite/gdb.fortran/vla-strings.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-strings.f90
create mode 100644 gdb/testsuite/gdb.fortran/vla-sub.f90
create mode 100644 gdb/testsuite/gdb.fortran/vla-value-sub-arbitrary.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-value-sub-finish.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-value-sub.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla-value.exp
create mode 100644 gdb/testsuite/gdb.fortran/vla.f90
create mode 100644 gdb/testsuite/gdb.mi/mi-vla-fortran.exp
create mode 100644 gdb/testsuite/gdb.mi/vla.f90
--
1.7.9.5
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [V4 00/21] Fortran dynamic array support 2015-01-14 13:49 Keven Boell @ 2015-05-28 20:36 ` Jan Kratochvil 2015-05-28 20:52 ` Joel Brobecker 2015-06-14 8:15 ` Jan Kratochvil 2016-07-07 8:30 ` Jan Kratochvil 2 siblings, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2015-05-28 20:36 UTC (permalink / raw) To: Keven Boell; +Cc: gdb-patches, Pedro Alves Hello, On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote: > This patch series add Fortran dynamic array support to gdb. I think this patch series is still not checked in, is it right? Do you have its more recent / rebased variant? Thanks, Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2015-05-28 20:36 ` Jan Kratochvil @ 2015-05-28 20:52 ` Joel Brobecker 0 siblings, 0 replies; 26+ messages in thread From: Joel Brobecker @ 2015-05-28 20:52 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Keven Boell, gdb-patches, Pedro Alves > > This patch series add Fortran dynamic array support to gdb. > I think this patch series is still not checked in, is it right? The latest update on the patch series is that we worked towards having a way to add dynamic attributes without always adding an extra field in (space-critical) struct type. The next step was to create a minimalistic patch that adds support for one of the array properties, and then work our way up. This is to allow both of us to understand the circumstances that explained the need for each hunk, because I couldn't figure it out myself. -- Joel ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2015-01-14 13:49 Keven Boell 2015-05-28 20:36 ` Jan Kratochvil @ 2015-06-14 8:15 ` Jan Kratochvil 2015-06-17 11:42 ` Boell, Keven 2016-07-07 8:30 ` Jan Kratochvil 2 siblings, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2015-06-14 8:15 UTC (permalink / raw) To: Keven Boell; +Cc: gdb-patches Hello, On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote: > This patch series add Fortran dynamic array support to gdb. does Intel some work in progress or plans for slices/subsets? It is a working feature in gfortran but currently not in GDB: http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-archer-vla-tests.patch#n2295 p var(1, 2:) = (21, 31) p var(:, :) = ((11, 12, 13, 14) (21, 22, 23, 24) (31, 32, 33, 34)) p var(:) = Wrong number of subscripts p var(:, :, :) = Wrong number of subscripts Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: [V4 00/21] Fortran dynamic array support 2015-06-14 8:15 ` Jan Kratochvil @ 2015-06-17 11:42 ` Boell, Keven 2015-07-01 12:43 ` Keven Boell 0 siblings, 1 reply; 26+ messages in thread From: Boell, Keven @ 2015-06-17 11:42 UTC (permalink / raw) To: Jan Kratochvil; +Cc: gdb-patches [-- Attachment #1.1: Type: text/plain, Size: 915 bytes --] Hi Jan, I didn't have much time to work on an updated VLA series. However, as there seems to be demand, I'll try to get an update to the mailing list by next week. Keven -----Original Message----- From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] Sent: Sunday, June 14, 2015 10:15 AM To: Boell, Keven Cc: gdb-patches@sourceware.org Subject: Re: [V4 00/21] Fortran dynamic array support Hello, On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote: > This patch series add Fortran dynamic array support to gdb. does Intel some work in progress or plans for slices/subsets? It is a working feature in gfortran but currently not in GDB: http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-archer-vla-tests.patch#n 2295 p var(1, 2:) = (21, 31) p var(:, :) = ((11, 12, 13, 14) (21, 22, 23, 24) (31, 32, 33, 34)) p var(:) = Wrong number of subscripts p var(:, :, :) = Wrong number of subscripts Jan [-- Attachment #1.2: smime.p7s --] [-- Type: application/pkcs7-signature, Size: 6608 bytes --] [-- Attachment #2: Type: text/plain, Size: 331 bytes --] Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2015-06-17 11:42 ` Boell, Keven @ 2015-07-01 12:43 ` Keven Boell 0 siblings, 0 replies; 26+ messages in thread From: Keven Boell @ 2015-07-01 12:43 UTC (permalink / raw) To: Boell, Keven, Jan Kratochvil; +Cc: gdb-patches https://sourceware.org/ml/gdb-patches/2015-07/msg00019.html Keven On 17.06.2015 13:41, Boell, Keven wrote: > Hi Jan, > > I didn't have much time to work on an updated VLA series. However, as there > seems to be demand, I'll try to get an update to the mailing list by next > week. > > Keven > > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Sunday, June 14, 2015 10:15 AM > To: Boell, Keven > Cc: gdb-patches@sourceware.org > Subject: Re: [V4 00/21] Fortran dynamic array support > > Hello, > > On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote: >> This patch series add Fortran dynamic array support to gdb. > > does Intel some work in progress or plans for slices/subsets? It is a > working > feature in gfortran but currently not in GDB: > > http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-archer-vla-tests.patch#n > 2295 > p var(1, 2:) = (21, 31) > p var(:, :) = ((11, 12, 13, 14) (21, 22, 23, 24) (31, 32, 33, 34)) > p var(:) = Wrong number of subscripts > p var(:, :, :) = Wrong number of subscripts > > > Jan > > > > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2015-01-14 13:49 Keven Boell 2015-05-28 20:36 ` Jan Kratochvil 2015-06-14 8:15 ` Jan Kratochvil @ 2016-07-07 8:30 ` Jan Kratochvil 2016-07-07 9:16 ` Bernhard Heckel 2 siblings, 1 reply; 26+ messages in thread From: Jan Kratochvil @ 2016-07-07 8:30 UTC (permalink / raw) To: Keven Boell; +Cc: gdb-patches Hello Keven, On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote: > This patch series add Fortran dynamic array support to gdb. this series is 1.5 years old and some partial upstreaming is also 1 year old, do you have some up-to-date remaining parts against FSF GDB trunk? I am trying to rebase it myself but just if you do not have it prepared already. Thanks, Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-07-07 8:30 ` Jan Kratochvil @ 2016-07-07 9:16 ` Bernhard Heckel 2016-07-07 9:23 ` Jan Kratochvil 0 siblings, 1 reply; 26+ messages in thread From: Bernhard Heckel @ 2016-07-07 9:16 UTC (permalink / raw) To: Jan Kratochvil, Keven Boell; +Cc: gdb-patches On 07/07/2016 10:30, Jan Kratochvil wrote: > Hello Keven, > > On Wed, 14 Jan 2015 14:49:32 +0100, Keven Boell wrote: >> This patch series add Fortran dynamic array support to gdb. > this series is 1.5 years old and some partial upstreaming is also 1 year old, > do you have some up-to-date remaining parts against FSF GDB trunk? > > I am trying to rebase it myself but just if you do not have it prepared > already. > > > Thanks, > Jan Hi Jan, I took over the Fortran patches from Keven and drive implementation of new features and bugfixes. I propose to create a branch on the GDB repo, containing all the bugfixes and features I have. => users/bheckel/fortran List of features, working on current mainline code: - Pointers, under review at the moment - Variable Length Strings - Alternative Entry Points - Extended types, Access members via fully qualified name - Setting breakpoints on internal subroutines - OOP, print access label of types (private, public) Bugfix: - Handle nameless block-data, GDB will crash during read of DWARF content. TBD: - Intrinsic's are in the series from Keven, but I haven't took a look on those. Regards, Bernhard Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [V4 00/21] Fortran dynamic array support 2016-07-07 9:16 ` Bernhard Heckel @ 2016-07-07 9:23 ` Jan Kratochvil 0 siblings, 0 replies; 26+ messages in thread From: Jan Kratochvil @ 2016-07-07 9:23 UTC (permalink / raw) To: Bernhard Heckel; +Cc: Keven Boell, gdb-patches Hello Bernhard, On Thu, 07 Jul 2016 11:16:05 +0200, Bernhard Heckel wrote: > I propose to create a branch on the GDB repo, containing all the bugfixes > and features I have. > => users/bheckel/fortran that is a great idea, > List of features, working on current mainline code: > - Pointers, under review at the moment > - Variable Length Strings just I would prefer a separate branch for each of these features. Besides more flexible upstreaming personally I am interested now in off-trunk VLA branch but probably not in the other off-trunk branches (as that functionality was not present in current/former Fedora GDB versions so missing those features is not a regression). Thanks, Jan ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2016-09-14 12:53 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <88072818E0A3D742B2B1AF16BBEC65A7263D8247@IRSMSX107.ger.corp.intel.com>
[not found] ` <20160707095439.GA6792@host1.jankratochvil.net>
[not found] ` <88072818E0A3D742B2B1AF16BBEC65A7263D990E@IRSMSX107.ger.corp.intel.com>
[not found] ` <20160714182743.GA10672@host1.jankratochvil.net>
[not found] ` <88072818E0A3D742B2B1AF16BBEC65A7263E6F2E@IRSMSX107.ger.corp.intel.com>
[not found] ` <20160715091352.GA8059@host1.jankratochvil.net>
[not found] ` <88072818E0A3D742B2B1AF16BBEC65A7263E8FD9@IRSMSX107.ger.corp.intel.com>
[not found] ` <20160716151310.GA14331@host1.jankratochvil.net>
[not found] ` <20160716151837.GA797@host1.jankratochvil.net>
[not found] ` <88072818E0A3D742B2B1AF16BBEC65A7263F0988@IRSMSX107.ger.corp.intel.com>
2016-08-16 13:59 ` [V4 00/21] Fortran dynamic array support Jan Kratochvil
2016-08-19 9:58 ` Bernhard Heckel
2016-08-21 17:04 ` Jan Kratochvil
2016-08-23 13:34 ` Bernhard Heckel
2016-08-25 17:06 ` Jan Kratochvil
2016-08-25 17:22 ` Jan Kratochvil
2016-08-26 7:17 ` Jan Kratochvil
2016-09-01 10:11 ` Bernhard Heckel
2016-09-02 13:44 ` Bernhard Heckel
2016-09-04 17:15 ` Jan Kratochvil
2016-09-07 10:29 ` Bernhard Heckel
2016-09-07 20:05 ` Jan Kratochvil
2016-09-12 21:05 ` Jan Kratochvil
2016-09-14 7:24 ` Bernhard Heckel
2016-09-14 12:53 ` Jan Kratochvil
2016-09-07 20:24 ` Jan Kratochvil
2016-09-01 9:48 ` Jan Kratochvil
2015-01-14 13:49 Keven Boell
2015-05-28 20:36 ` Jan Kratochvil
2015-05-28 20:52 ` Joel Brobecker
2015-06-14 8:15 ` Jan Kratochvil
2015-06-17 11:42 ` Boell, Keven
2015-07-01 12:43 ` Keven Boell
2016-07-07 8:30 ` Jan Kratochvil
2016-07-07 9:16 ` Bernhard Heckel
2016-07-07 9:23 ` Jan Kratochvil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox