https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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
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 >=
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
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;
}
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
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #8 from Richard Biener
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
>
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:
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |8.0
18 matches
Mail list logo
