From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0B1463850406; Mon, 1 Mar 2021 21:57:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0B1463850406 From: "aatsnps at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/99334] New: Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame Date: Mon, 01 Mar 2021 21:57:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 6.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aatsnps at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 21:57:37 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99334 Bug ID: 99334 Summary: Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aatsnps at gmail dot com Target Milestone: --- Created attachment 50281 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D50281&action=3Dedit Function gp_fs_solve_top_cons in the attached gp_fs_solve_gcc.i file will h= ave this issue in the generated DWARF Filing a bug for tracking this: Compile Time Switches Used: gcc -Werror -Wall -Wpointer-arith -Wnested-exte= rns -Wmissing-prototypes -Wextra -Wmissing-braces -Wformat=3D2 -Wno-format-nonl= iteral -Wno-format-nonliteral -Wno-unused-parameter -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -fdiagnostics-show-option -Wno-missing-field-initializers -fno-dollars-in-identifiers -Wno-unused-local-typedefs -Xassembler -mrelax-relocations=3Dno -m64 -msse2= -fPIC -D__NO_STRING_INLINES -mstackrealign -DLINUX -m64 -rdynamic -DMM_MODE=3D0 -DLINUX_X86_64 -fPIC -DLINUX_X86_64 -DLONG_PTR_64 -DVM_LITTLE_ENDIAN -DMM_MODE=3D0 -rdynamic -O3 -fPIC -fomit-frame-pointer -fPIC -O3 -msse2 -fno-strict-aliasing -fPIC -fomit-frame-pointer -c gp_fs_solve_gcc.i On Tue, Oct 13, 2020 at 5:10 AM AJ D via Gcc wrote: > > Hi, > > > > I have a function for which GCC is generating the following code (just > showing the relevant snippet here). > > > > 0000000000005a70 : > > 5a70: 4c 8d 54 24 08 lea 0x8(%rsp),%r10 > > 5a75: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp > > 5a79: 41 ff 72 f8 pushq -0x8(%r10) > > 5a7d: 55 push %rbp > > 5a7e: 48 89 e5 mov %rsp,%rbp > > 5a81: 41 57 push %r15 > > 5a83: 41 56 push %r14 > > 5a85: 41 55 push %r13 > > 5a87: 41 54 push %r12 > > : > > 5b08: 5b pop %rbx > > 5b09: 41 5a pop %r10 > > 5b0b: 41 5c pop %r12 > > 5b0d: 41 5d pop %r13 > > 5b0f: 41 5e pop %r14 > > 5b11: 41 5f pop %r15 > > 5b13: 5d pop %rbp > > *=3D> 5b14: 49 8d 62 f8 lea -0x8(%r10),%rsp* > > 5b18: c3 retq > > > > I am using a SIGPROF based CPU profiler (Google CPU Profiler) to profile = my > code. The SIGPROF handler (of the Google CPU Profiler) tries to unwind the > stack (using libunwind) every time it gets a SIGPROF. And libunwind (used > for unwinding the stack) uses DWARF unwind table (dumped by gcc -O3 > -mstackrealign -fomit-frame-pointer). > > > And I noticed that I get a crash every time my code gets interrupted by > SIGPROF while my program is in the middle of setting / resetting frame > pointer and the frame pointer %rbp happens to point to the parent/previous > frame at that point, for example, in instruction *5b14* (shown above with > =3D> and red). > > > > *=3D> 5b14: 49 8d 62 f8 lea -0x8(%r10),%rsp* > > > DWARF dumped by GCC for the snippet shown above is the following: > > > > 000002f4 0000000000000044 000002f8 FDE cie=3D00000000 > pc=3D0000000000005a70..0000000000005d7c > > DW_CFA_advance_loc: 5 to 0000000000005a75 > > DW_CFA_def_cfa: r10 (r10) ofs 0 > > DW_CFA_advance_loc: 9 to 0000000000005a7e > > DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0) > > DW_CFA_advance_loc: 11 to 0000000000005a89 > > DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) > > DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) > > DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) > > DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) > > DW_CFA_advance_loc: 5 to 0000000000005a8e > > DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref) > > DW_CFA_advance_loc: 4 to 0000000000005a92 > > *>> DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48)* > > DW_CFA_advance_loc1: 121 to 0000000000005b0b > > DW_CFA_remember_state > > *>> DW_CFA_def_cfa: r10 (r10) ofs 0* > > DW_CFA_advance_loc: 13 to 0000000000005b18 > > DW_CFA_def_cfa: r7 (rsp) ofs 8 > > DW_CFA_advance_loc: 8 to 0000000000005b20 > > DW_CFA_restore_state > > > > 000002f4 0000000000000044 000002f8 FDE cie=3D00000000 > pc=3D0000000000005a70..0000000000005d7c > > LOC CFA rbx rbp r12 r13 r14 r15 ra > > 0000000000005a70 rsp+8 u u u u u u c-8 > > 0000000000005a75 r10+0 u u u u u u c-8 > > 0000000000005a7e r10+0 u exp u u u u c-8 > > 0000000000005a89 r10+0 u exp exp exp exp exp c-8 > > 0000000000005a8e exp u exp exp exp exp exp c-8 > > 0000000000005a92 exp exp exp exp exp exp exp c-8 > > *0000000000005b0b r10+0 **exp **exp exp exp exp exp c-8* > > 0000000000005b18 rsp+8 exp exp exp exp exp exp c-8 > > 0000000000005b20 exp exp exp exp exp exp exp c-8 > > > > And if you see here, the DWARF expression for fetching the CFA is correct, > but what about the DWARF expression for fetching the value of %rbx? > > > > *>> DW_CFA_expression: r3 (rbx) (DW_OP_breg6 (rbp): -48)* > > > > Value of %rbx is (in DWARF) is =E2=80=9C%rbp relative=E2=80=9D and since = %rbp is pointing > to the wrong (parent/previous) frame, we will obviously get garbage for t= he > value of %rbx. > > > > If you look at the generated DWARF carefully, pretty much everything is > =E2=80=98%rbp relative=E2=80=99, so values for each of these registers ca= nnot be restored > in this scenario. > > > > DW_CFA_expression: r15 (r15) (DW_OP_breg6 (rbp): -8) > > DW_CFA_expression: r14 (r14) (DW_OP_breg6 (rbp): -16) > > DW_CFA_expression: r13 (r13) (DW_OP_breg6 (rbp): -24) > > DW_CFA_expression: r12 (r12) (DW_OP_breg6 (rbp): -32) > > > > I was just wondering, instead of making these %rbp-relative, could we have > made this CFA-relative? That would have taken care of this particular > issue, since CFA is correctly maintained/restored in this example. > > > > Another question, is there a known work around for this issue? In case you do not get a sufficient answer here it might be useful to report a bug in bugzilla so it doesn't get lost. Richard. > > > Regards > > AJ The actual function where this issue can be seen is gp_fs_solve_top_cons an= d it has been preserved in the attached gp_fs_solve_gcc.i file: 0000000000005a70 : 5a70: 4c 8d 54 24 08 lea 0x8(%rsp),%r10 5a75: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 5a79: 41 ff 72 f8 pushq -0x8(%r10) 5a7d: 55 push %rbp 5a7e: 48 89 e5 mov %rsp,%rbp 5a81: 41 57 push %r15 5a83: 41 56 push %r14 5a85: 41 55 push %r13 5a87: 41 54 push %r12 : 5b08: 5b pop %rbx 5b09: 41 5a pop %r10 5b0b: 41 5c pop %r12 5b0d: 41 5d pop %r13 5b0f: 41 5e pop %r14 5b11: 41 5f pop %r15 5b13: 5d pop %rbp =3D> 5b14: 49 8d 62 f8 lea -0x8(%r10),%rsp 5b18: c3 retq=