[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #17 from Jakub Jelinek  ---
Closing as a GDB bug, we aren't going to revert -freorder-blocks-and-partition
by default and it affects lots of code with the hot/cold partition, so it
really needs to be fixed in GDB and the GDB folks are actively working on that
(thanks for that).  Not sure if there is a GDB bugzilla bug number for this, if
yes, we should add a cross-reference.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #16 from Kevin Buettner  ---
Created attachment 43671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43671=edit
GDB patch - dwarf2read.c

I've attached the GDB patch that I'm currently testing.  When I try it against
either Jakub's test case or in the one that I only slightly simplified, I find
that I can step into foo() as expected.

I see no regressions when testing against the GDB testsuite using either

1) /bin/gcc on my Fedora 23 machine

or

2) A build of GCC using recent development sources

However, if I use #2 along with -O2, I see some apparent regressions.  I say
"apparent" because the ones that I've investigated so far aren't really
regressions.  It turns out that -O2 causes much of the initial part of the
function (upon which a breakpoint is being set) to be optimized away and having
an extra breakpoint on the .cold location will sometimes cause GDB to consider
a test with a "continue" to be a success due to being able to hit some other
breakpoint, even if it's not at the correct line/location. (Yes, these tests
should probably be revised so that doesn't happen. That said, the gdb testsuite
doesn't really work very well with everything compiled with -O2 anyway.)

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #15 from Kevin Buettner  ---
I've been focusing my attention on dwarf2read.c (in GDB).  I have a patch which
fixes this problem, but which introduces a bunch of test suite regressions. 
(So it's not a very good patch.)  I'll be away on Friday, but will resume
looking at it when I return on Monday.

Anyway, with that not-very-good patch in place, this is what I see:

(gdb) b qux
Breakpoint 1 at 0x4005b0: file vau2.c, line 24.
(gdb) x/i 0x400460
   0x400460 <_Z3quxP1C.cold.0>: callq  0x400430 
(gdb) 
   0x400465:nopw   %cs:0x0(%rax,%rax,1)
(gdb) 
   0x40046f:nop
(gdb) run
Starting program: /mesquite2/.ironwood2/84550/vau2 

Breakpoint 1, qux (p=0x7fffe098) at vau2.c:24
24if (!p->c) __builtin_abort ();
(gdb) s
25a = p->c->b;
(gdb) s
27b = (a->a == 4)
(gdb) s
foo (p=0x7fffe08c) at vau2.c:8
8 return false;

Note that only one location is set for the breakpoint in qux.  Also, I'm now
able to step into foo().

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #14 from Jakub Jelinek  ---
 In addition to reordering basic blocks in the compiled function, in
 order to reduce number of taken branches, partitions hot and cold
 basic blocks into separate sections of the assembly and '.o' files,
 to improve paging and cache locality performance.
is what we say about -freorder-blocks-and-partition in the documentation, when
functions are normally placed in .text section rather than anything different,
the cold basic blocks go into .text.cold subsection and the linker merges all
those cold subsections from all objects into one part of the resulting .text
section, so unlikely used code from all the functions is adjacent and hot code
from all of them elsewhere too.  The cold partition could end up either below
or above the hot partition, it is purely up to the linker to decide that.
As written above, the real entrypoint to the function can be found in DWARF by
checking DW_AT_entry_pc if it exists, or if it doesn't, as the base address of
the function which is the lowest address of the first range if it has
DW_AT_ranges, or if it has DW_AT_{low,high}_pc as the DW_AT_low_pc.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #13 from Kevin Buettner  ---
(In reply to Kevin Buettner from comment #11)

> This code, which is in find_pc_partial_function_gnu_ifunc(), incorrectly
> identifies this address, 0x400590, as belonging to qux:
> 
>   if (mapped_pc >= cache_pc_function_low
>   && mapped_pc < cache_pc_function_high
>   && section == cache_pc_function_section)
> goto return_cached_value;

I've determined that if this code is disabled, then things work.  I'm not
suggesting this as a fix, just adding another data point.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #12 from Kevin Buettner  ---
I'll note, too, that just setting a breakpoint on qux and then looking at the
locations reveals another problem...

(gdb) b qux
Breakpoint 1 at 0x400460: qux. (2 locations)
(gdb) info break
Num Type   Disp Enb AddressWhat
1   breakpoint keep y
1.1 y 0x00400460 in qux(C*) at vau2.c:24
1.2 y 0x004005b0 in qux(C*) at vau2.c:24
(gdb) x/4i 0x400460
   0x400460 :  callq  0x400430 
   0x400465:nopw   %cs:0x0(%rax,%rax,1)
   0x40046f:nop
   0x400470 :   sub$0x28,%rsp
(gdb) x/4i 0x4005b0
   0x4005b0 <_Z3quxP1C>:push   %rbx
   0x4005b1 <_Z3quxP1C+1>:  mov(%rdi),%rax
   0x4005b4 <_Z3quxP1C+4>:  test   %rax,%rax
   0x4005b7 <_Z3quxP1C+7>:  je 0x400460 

Placing a breakpoint on 0x400460 is incorrect since this is not an actual entry
point to the function.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #11 from Kevin Buettner  ---
I've simplified Jakub's example slightly:

--- vau2.c ---
struct A { int a; };
struct B { struct A *b; };
struct C { struct B *c; };

__attribute__((noipa)) bool
foo (struct A *p)
{
  return false;
}

__attribute__((noipa)) int
baz (int x)
{
  return 0;
}

__attribute__((noipa)) void
qux (struct C *p)
{
  struct A *a;
  bool b;
  int c;

  if (!p->c) __builtin_abort ();
  a = p->c->b;

  b = (a->a == 4)
&& (foo (a));

  c = baz (0);
  baz (b);
}

int
main ()
{
  struct A a = { 4 };
  struct B b = {  };
  struct C c = {  };
  qux ();
  return 0;
}
--- end vau2.c ---

When I compile this via "g++ -O2 -g vau2.c -o vau2", and load it into gdb, it
exhibits the same behavior shown by Jakub.  I.e. the following sequence...

b qux
run
s
s
s

... does not stop in foo as expected.  The program instead exits.

It turns out that qux consists of two disjoint pieces which, for some reason,
are separated by a lot of other code, e.g. main, _start, foo, baz, and a lot of
other stuff too.  Here's what it looks like:

   0x400460 :  callq  0x400430 
   0x400465:nopw   %cs:0x0(%rax,%rax,1)
   0x40046f:nop
   0x400470 :   sub$0x28,%rsp
   0x400474 : lea0xc(%rsp),%rax
   0x400479 : lea0x18(%rsp),%rdi
   0x40047e :movl   $0x4,0xc(%rsp)
   0x400486 :mov%rax,0x10(%rsp)
   0x40048b :lea0x10(%rsp),%rax
   0x400490 :mov%rax,0x18(%rsp)
   0x400495 :callq  0x4005b0 <_Z3quxP1C>
   0x40049a :xor%eax,%eax
   0x40049c :add$0x28,%rsp
   0x4004a0 :retq   
   0x4004a1:nopw   %cs:0x0(%rax,%rax,1)
   0x4004ab:nopl   0x0(%rax,%rax,1)
   0x4004b0 <_start>:   xor%ebp,%ebp
   0x4004b2 <_start+2>: mov%rdx,%r9
   0x4004b5 <_start+5>: pop%rsi
   0x4004b6 <_start+6>: mov%rsp,%rdx
   0x4004b9 <_start+9>: and$0xfff0,%rsp
   0x4004bd <_start+13>:push   %rax
   0x4004be <_start+14>:push   %rsp
   0x4004bf <_start+15>:mov$0x400660,%r8
   0x4004c6 <_start+22>:mov$0x4005f0,%rcx
   0x4004cd <_start+29>:mov$0x400470,%rdi
   0x4004d4 <_start+36>:callq  0x400440 <__libc_start_main@plt>
   0x4004d9 <_start+41>:hlt
...
   0x400590 :  xor%eax,%eax
   0x400592 :retq   
   0x400593:nopl   (%rax)
   0x400596:nopw   %cs:0x0(%rax,%rax,1)
   0x4005a0 : xor%eax,%eax
   0x4005a2 :   retq   
   0x4005a3:nopl   (%rax)
   0x4005a6:nopw   %cs:0x0(%rax,%rax,1)
   0x4005b0 <_Z3quxP1C>:push   %rbx
   0x4005b1 <_Z3quxP1C+1>:  mov(%rdi),%rax
   0x4005b4 <_Z3quxP1C+4>:  test   %rax,%rax
   0x4005b7 <_Z3quxP1C+7>:  je 0x400460 
   0x4005bd <_Z3quxP1C+13>: mov(%rax),%rdi
   0x4005c0 <_Z3quxP1C+16>: xor%ebx,%ebx
   0x4005c2 <_Z3quxP1C+18>: cmpl   $0x4,(%rdi)
   0x4005c5 <_Z3quxP1C+21>: je 0x4005d8 <_Z3quxP1C+40>
   0x4005c7 <_Z3quxP1C+23>: xor%edi,%edi
   0x4005c9 <_Z3quxP1C+25>: callq  0x4005a0 
   0x4005ce <_Z3quxP1C+30>: mov%ebx,%edi
   0x4005d0 <_Z3quxP1C+32>: pop%rbx
   0x4005d1 <_Z3quxP1C+33>: jmp0x4005a0 
   0x4005d3 <_Z3quxP1C+35>: nopl   0x0(%rax,%rax,1)
   0x4005d8 <_Z3quxP1C+40>: callq  0x400590 
   0x4005dd <_Z3quxP1C+45>: xor%edi,%edi
   0x4005df <_Z3quxP1C+47>: movzbl %al,%ebx
   0x4005e2 <_Z3quxP1C+50>: callq  0x4005a0 
   0x4005e7 <_Z3quxP1C+55>: mov%ebx,%edi
   0x4005e9 <_Z3quxP1C+57>: pop%rbx
   0x4005ea <_Z3quxP1C+58>: jmp0x4005a0 
   0x4005ec:nopl   0x0(%rax)

Within GDB, this is where things go wrong:

top-gdb> bt 4
#0  find_pc_partial_function_gnu_ifunc (pc=4195728, name=0x7fffdd28, 
address=0x7fffdd18, endaddr=0x7fffdd20, is_gnu_ifunc_p=0x0)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/blockframe.c:213
#1  0x00553281 in find_pc_partial_function (pc=4195728, 
name=0x7fffdd28, address=0x7fffdd18, endaddr=0x7fffdd20)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/blockframe.c:323
#2  0x006b6aec in fill_in_stop_func (gdbarch=0x1249170, 
ecs=0x7fffdcd0)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/infrun.c:4303
#3  0x006baf13 in process_event_stop_test (ecs=0x7fffdcd0)
at
/ironwood1/sourceware-git/mesquite-native-thread_handle_to_thread_info/bld/../../binutils-gdb/gdb/infrun.c:6494

That pc value is actually the first address for foo(), which is what we want:

top-gdb> p/x pc
$22 = 0x400590

(Refer to my 

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #10 from Pedro Alves  ---
It sounds that way, but I haven't verified, e.g., by trying older versions of
gdb, and/or bisecting.

Kevin, in addition to trying older versions of gdb with
freorder-blocks-and-partition, I'm curious about why gdb finds different ends
of prologue when stepping vs when setting a breakpoint.  It may be that making
both spots use the same logic (e.g., it may one is skipping instructions
manually using the heuristic unwinders and another is using the line tables)
will be good enough of a stopgap to unblock this bug.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #9 from Jakub Jelinek  ---
My limited understanding is this is a GDB bug and that it basically never
worked properly with -freorder-blocks-and-partition.  So not really sure how we
could work around it in GCC.  Pedro, do you agree?

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #8 from Richard Biener  ---
Raising priority.  A fix can be either in GCC or in gdb (we can just document a
new gdb requirement).

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #7 from Jakub Jelinek  ---
(In reply to Pedro Alves from comment #6)
> I see the same thing with your reduced testcase:
> 
> ~~~
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x400580
> infrun: stepped into subroutine
> infrun: inserting step-resume breakpoint at 0x400410
> infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current
> thread [process 13966] at 0x400580
> ~~~
> 
> 0x400410 is never hit.
> 
> With:
> 
> (gdb) disassemble /s qux
> Dump of assembler code for function qux(C*):
> t.c:
> 33if (!p->c) __builtin_abort ();
>0x00400410 <+0>: callq  0x400400 
>0x00400415:  nopw   %cs:0x0(%rax,%rax,1)
>0x0040041f:  nop
> ...
>0x00400578 <+16>:nopl   0x0(%rax,%rax,1)
> 
> 9 return false;
>0x00400580 <+0>: xor%eax,%eax
>0x00400582 <+2>: retq   
>0x00400583:  nopl   (%rax)
>0x00400586:  nopw   %cs:0x0(%rax,%rax,1)
> ---Type  to continue, or q  to quit---
> 
> ... we see that "foo" is sharing the tail end of qux?

No, they don't share anything, seems disassemble /s is also confused about it.

qux is only:
33if (!p->c) __builtin_abort ();
   0x00400430 <+0>: callq  0x400420 

(_Z3quxP1C.cold.0 in .symtab, the cold part of the function) and
26  __attribute__((noipa)) void
27  qux (struct C *p)
28  {
29struct A *a;
30bool b;
31int c;
32  
33if (!p->c) __builtin_abort ();
=> 0x00400590 <+0>: push   %rbp
   0x00400591 <+1>: push   %rbx
   0x00400592 <+2>: sub$0x8,%rsp
   0x00400596 <+6>: mov(%rdi),%rax
   0x00400599 <+9>: test   %rax,%rax
   0x0040059c <+12>:je 0x400430 

34a = p->c->b;
   0x004005a2 <+18>:mov(%rax),%rbp

35  
36b = (a->a == 4)
   0x004005a5 <+21>:xor%ebx,%ebx
   0x004005a7 <+23>:cmpl   $0x4,0x0(%rbp)
   0x004005ab <+27>:je 0x4005c0 <_Z3quxP1C+48>

37  && (foo (a)
38  || bar (a, 0));
39  
40c = baz (0);
   0x004005ad <+29>:xor%edi,%edi
   0x004005af <+31>:callq  0x400580 

41baz (b);
   0x004005b4 <+36>:add$0x8,%rsp
   0x004005b8 <+40>:mov%ebx,%edi
   0x004005ba <+42>:pop%rbx
   0x004005bb <+43>:pop%rbp
   0x004005bc <+44>:jmp0x400580 
   0x004005be <+46>:xchg   %ax,%ax
   0x004005c0 <+48>:mov%rbp,%rdi
   0x004005c3 <+51>:mov$0x1,%ebx
   0x004005c8 <+56>:callq  0x400560 
   0x004005cd <+61>:test   %al,%al
   0x004005cf <+63>:jne0x4005ad <_Z3quxP1C+29>
   0x004005d1 <+65>:xor%esi,%esi
   0x004005d3 <+67>:mov%rbp,%rdi
   0x004005d6 <+70>:callq  0x400570 
   0x004005db <+75>:movzbl %al,%ebx
   0x004005de <+78>:jmp0x4005ad <_Z3quxP1C+29>
which is the actual hot part of the function, _Z3quxP1C symbol in .symtab.

We have:
 <1>: Abbrev Number: 10 (DW_TAG_subprogram)
   DW_AT_external: 1
   DW_AT_name: qux
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 27
   DW_AT_decl_column : 1
   DW_AT_linkage_name: (indirect string, offset: 0x8): _Z3quxP1C
   DW_AT_ranges  : 0x0
   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
   DW_AT_GNU_all_call_sites: 1
   DW_AT_sibling : <0x18c>
so there is no DW_AT_entry_pc nor DW_AT_low_pc attribute, so the base address
and entry address of the function are the lowest address of the first range in
DW_AT_ranges, which is:
Offset   BeginEnd
 00400590 004005e0 
 00400430 00400435 
 
and that is how GDB should be treating this (both for disassemble/s, as two
separate ranges to print, first the 400590 ... 4005e0 and then 400430 ...
400435, with entry address being 400590.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #6 from Pedro Alves  ---
I see the same thing with your reduced testcase:

~~~
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400580
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x400410
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 13966] at 0x400580
~~~

0x400410 is never hit.

With:

(gdb) disassemble /s qux
Dump of assembler code for function qux(C*):
t.c:
33if (!p->c) __builtin_abort ();
   0x00400410 <+0>: callq  0x400400 
   0x00400415:  nopw   %cs:0x0(%rax,%rax,1)
   0x0040041f:  nop
...
   0x00400578 <+16>:nopl   0x0(%rax,%rax,1)

9 return false;
   0x00400580 <+0>: xor%eax,%eax
   0x00400582 <+2>: retq   
   0x00400583:  nopl   (%rax)
   0x00400586:  nopw   %cs:0x0(%rax,%rax,1)
---Type  to continue, or q  to quit---

... we see that "foo" is sharing the tail end of qux?

And we see that "0x400410", where GDB things foo's prologue ends,
is actually the end of qux's prologue:

(gdb) disassemble /s foo
Dump of assembler code for function qux(C*):
t.c:
33if (!p->c) __builtin_abort ();
   0x00400410 <+0>: callq  0x400400 
   0x00400415:  nopw   %cs:0x0(%rax,%rax,1)
   0x0040041f:  nop

When we do "b foo", gdb sets a breakpoint at 0x400580 instead (passed foo's
prologue).  I don't know why it gets it wrong when stepping into the function.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #5 from Jakub Jelinek  ---
GCC bisection reveals that this started misbehaving with r249105 when
-freorder-blocks-and-partition has been turned on by default, and with explicit
-freorder-blocks-and-partition it started failing with r249070 abort has been
marked as cold; before that this small testcase didn't use hot/cold
partitioning, while now it does.

The only instruction in the cold section in this testcase is actually:
callabort
so it is unclear to me how this prevents step from working properly.  And
strangely, if I do
b main
r
s
s
s
s
s
(many times) and I step through into qux that way and step through the same
statement as after b qux; r, it works fine.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

--- Comment #4 from Pedro Alves  ---

infrun: stepped into subroutine
#1  infrun: inserting step-resume breakpoint at 0x5b88b8
#2  infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current
thread [process 25164] at 0x853b60
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   -1.0.0 [process -1],
infrun:   status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
a.f90:8:0:


The #1 above is GDB placing a breakpoint after the prologue of the subroutine,
to skip the prologue and stop at the first line of user code.  The #2 above is
GDB continuing the thread until it hits that internal breakpoint.  But it looks
like the breakpoint isn't ever hit?

It sounds like the end-of-prologue address might be incorrect.   0x5b88b8 seems
too off from 0x853b60.  Should usually be an address close and higher than
0x853b60.

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-28
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
I can reproduce it also with simplified:
struct A { int a; };
struct B { struct A *b; };
struct C { struct B *c; };

__attribute__((noipa)) bool
foo (struct A *p)
{
  asm volatile ("" : : "r" (p) : "memory");
  return false;
}

__attribute__((noipa)) bool
bar (struct A *p, void *q)
{
  asm volatile ("" : : "r" (p), "r" (q) : "memory");
  return false;
}

__attribute__((noipa)) int
baz (int x)
{
  asm volatile ("" : : "r" (x) : "memory");
  return 0;
}

__attribute__((noipa)) void
qux (struct C *p)
{
  struct A *a;
  bool b;
  int c;

  if (!p->c) __builtin_abort ();
  a = p->c->b;

  b = (a->a == 4)
&& (foo (a)
|| bar (a, 0));

  c = baz (0);
  baz (b);
}

int
main ()
{
  struct A a = { 4 };
  struct B b = {  };
  struct C c = {  };
  qux ();
  return 0;
}

compiled with -g -O2 by trunk gcc on x86_64-linux.  If I do
b qux
r
s
s
s
then I get:
(gdb) b qux
Breakpoint 1 at 0x400440: qux. (2 locations)
(gdb) r
Starting program: /home/jakub/src/gcc/obj08/gcc/vau 
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.26-24.fc27.x86_64

Breakpoint 1, qux(C*) () at vau.c:33
33if (!p->c) __builtin_abort ();
Missing separate debuginfos, use: dnf debuginfo-install
libgcc-7.3.1-2.fc27.x86_64
(gdb) s
34a = p->c->b;
(gdb) s
36b = (a->a == 4)
(gdb) s
[Inferior 1 (process 25359) exited normally]

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||palves at redhat dot com

--- Comment #2 from Jakub Jelinek  ---
I can reproduce it both with normal optimized built f951 and when trans-stmt.o
is built with -gno-statement-frontiers -gno-inline-points.
1646  gcc_assert (sym->assoc);
(gdb) s
1647  e = sym->assoc->target;
(gdb) s
1650&& (gfc_is_class_scalar_expr (e)
(gdb) set debug infrun 1
(gdb) s
infrun: clear_proceed_status_thread (process 25164)
infrun: proceed (addr=0x, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 25164
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x98c855
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x98c858
infrun: stepping inside range [0x98c855-0x98c868]
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x98c858
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x98c85b
infrun: stepping inside range [0x98c855-0x98c868]
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x98c85b
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x98c85e
infrun: stepping inside range [0x98c855-0x98c868]
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x98c85e
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x98c862
infrun: stepping inside range [0x98c855-0x98c868]
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x98c862
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x98cf08
infrun: keep going
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x98cf08
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x98cf0b
infrun: stepping inside range [0x98cf08-0x98cf1b]
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x98cf0b
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x853b60
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x5b88b8
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread
[process 25164] at 0x853b60
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun:   -1.0.0 [process -1],
infrun:   status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
a.f90:8:0:

 associate (n_array => b%array%n)

internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1278
0x5ba616 gfc_get_element_type(tree_node*)
../../gcc/fortran/trans-types.c:1278
0x98d1ee trans_associate_var
../../gcc/fortran/trans-stmt.c:1741
0x9921b1 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2064
0x915f37 trans_code
../../gcc/fortran/trans.c:1924
0x941d5d gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6497
0x8ccc46 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x8ccc46 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x9130ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
infrun: target_wait (-1.0.0, status) =
infrun:   25164.25164.0 [process 25164],
infrun:   status->kind = exited, status = 4
infrun: TARGET_WAITKIND_EXITED

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Is that an optimized f951?

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |8.0