public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/99334] New: Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
@ 2021-03-01 21:57 aatsnps at gmail dot com
  2021-03-01 22:18 ` [Bug c/99334] " jakub at gcc dot gnu.org
                   ` (17 more replies)
  0 siblings, 18 replies; 19+ messages in thread
From: aatsnps at gmail dot com @ 2021-03-01 21:57 UTC (permalink / raw)
  To: gcc-bugs

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

            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=50281&action=edit
Function gp_fs_solve_top_cons in the attached gp_fs_solve_gcc.i file will have
this issue in the generated DWARF

Filing a bug for tracking this:

Compile Time Switches Used: gcc -Werror -Wall -Wpointer-arith -Wnested-externs
-Wmissing-prototypes -Wextra -Wmissing-braces -Wformat=2 -Wno-format-nonliteral
-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=no -m64 -msse2 -fPIC
-D__NO_STRING_INLINES -mstackrealign -DLINUX -m64 -rdynamic -DMM_MODE=0
-DLINUX_X86_64 -fPIC -DLINUX_X86_64 -DLONG_PTR_64 -DVM_LITTLE_ENDIAN
-DMM_MODE=0 -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 <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
>
>
> I have a function for which GCC is generating the following code (just
> showing the relevant snippet here).
>
>
>
> 0000000000005a70 <gp_fs_solve_top_cons>:
>
>     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
>
> *=>    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
> => and red).
>
>
>
> *=>    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=00000000
> pc=0000000000005a70..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=00000000
> pc=0000000000005a70..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 “%rbp relative” and since %rbp is pointing
> to the wrong (parent/previous) frame, we will obviously get garbage for the
> value of %rbx.
>
>
>
> If you look at the generated DWARF carefully, pretty much everything is
> ‘%rbp relative’, so values for each of these registers cannot 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 and it
has been preserved in the attached gp_fs_solve_gcc.i file:

0000000000005a70 <gp_fs_solve_top_cons>:
    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
=>  5b14:   49 8d 62 f8            lea    -0x8(%r10),%rsp
    5b18:   c3                      retq

^ permalink raw reply	[flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-09-22  5:22 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-01 21:57 [Bug c/99334] New: Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame aatsnps at gmail dot com
2021-03-01 22:18 ` [Bug c/99334] " jakub at gcc dot gnu.org
2021-03-02  7:47 ` [Bug debug/99334] " rguenth at gcc dot gnu.org
2021-03-08 21:53 ` aatsnps at gmail dot com
2021-03-08 22:49 ` pinskia at gcc dot gnu.org
2021-03-19 19:18 ` aatsnps at gmail dot com
2021-03-20  4:39 ` aatsnps at gmail dot com
2021-03-20  4:46 ` aatsnps at gmail dot com
2021-03-20  9:39 ` jakub at gcc dot gnu.org
2021-03-23 17:20 ` jakub at gcc dot gnu.org
2021-03-26 16:01 ` jakub at gcc dot gnu.org
2021-03-26 23:23 ` cvs-commit at gcc dot gnu.org
2021-03-30 22:41 ` cvs-commit at gcc dot gnu.org
2021-04-20 23:34 ` cvs-commit at gcc dot gnu.org
2021-04-22 16:52 ` cvs-commit at gcc dot gnu.org
2021-04-22 17:10 ` jakub at gcc dot gnu.org
2021-09-22  4:06 ` aatsnps at gmail dot com
2021-09-22  5:19 ` pinskia at gcc dot gnu.org
2021-09-22  5:22 ` pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).