[Bug c/99334] New: Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[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]

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

[Bug c/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 6.2 is not supported anymore (nor 7.x).  I can't reproduce the code you
posted with any of 5.5, 6.4.1, 7.4.1 nor current trunk.
If you can't reproduce with a supported compiler, there is nothing to do, if
you can, you'll need to specify version and how exactly it has been configured
e.g. if you have some non-standard default --with-tune=, --with-arch= etc.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-03-02
             Status|UNCONFIRMED                 |WAITING
             Target|                            |x86_64-linux

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[aatsnps at gmail dot com]

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

--- Comment #2 from AJ D <aatsnps at gmail dot com> ---
The problem seems to have been addressed in gcc-8.x, at least in this
particular function.

I could reproduce this issue in gcc-7.4, but not with gcc-8.2, as can be seen
below.

Will have to check if this issue is showing up in any other functions.

odcphy-vg-1294> module load gcc/7.4.0
odcphy-vg-1294> ./reproduce.csh
000002f0 0000000000000044 000002f4 FDE cie=00000000
pc=0000000000006570..000000000000680a
   LOC           CFA      rbx   rbp   r12   r13   r14   r15   ra      
0000000000006570 rsp+8    u     u     u     u     u     u     c-8   
0000000000006575 r10+0    u     u     u     u     u     u     c-8   
000000000000657e r10+0    u     exp   u     u     u     u     c-8   
0000000000006589 r10+0    u     exp   exp   exp   exp   exp   c-8   
000000000000658e exp      u     exp   exp   exp   exp   exp   c-8   
0000000000006592 exp      exp   exp   exp   exp   exp   exp   c-8   
00000000000065f5 r10+0    exp   exp   exp   exp   exp   exp   c-8   
0000000000006602 rsp+8    exp   exp   exp   exp   exp   exp   c-8   
0000000000006608 exp      exp   exp   exp   exp   exp   exp   c-8   
odcphy-vg-1294>


odcphy-vg-1294> module load gcc/8.2.0
odcphy-vg-1294> ./reproduce.csh
000002c8 0000000000000034 000002cc FDE cie=00000000
pc=0000000000006450..000000000000676f
   LOC           CFA      rbx   rbp   r12   r13   r14   r15   ra      
0000000000006450 rsp+8    u     u     u     u     u     u     c-8   
0000000000006451 rsp+16   u     c-16  u     u     u     u     c-8   
0000000000006454 rbp+16   u     c-16  u     u     u     u     c-8   
000000000000645a rbp+16   u     c-16  u     c-40  c-32  c-24  c-8   
000000000000645f rbp+16   u     c-16  c-48  c-40  c-32  c-24  c-8   
0000000000006463 rbp+16   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
0000000000006518 rsp+8    c-56  c-16  c-48  c-40  c-32  c-24  c-8   
0000000000006520 rbp+16   c-56  c-16  c-48  c-40  c-32  c-24  c-8   
0000000000006550 rsp+8    c-56  c-16  c-48  c-40  c-32  c-24  c-8   
odcphy-vg-1294>

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |8.2
             Status|WAITING                     |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
so clsoing as fixed as GCC 7.x (and before) are no longer supported.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[aatsnps at gmail dot com]

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

AJ D <aatsnps at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---
            Version|6.2.0                       |9.2.0

--- Comment #4 from AJ D <aatsnps at gmail dot com> ---
I can reproduce this issue with gcc 9.2, but this time, on a different routine
(not on the previously reported routine).


GCC Version
============
gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


GCC Configuration
=================
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/depot/qsc/QSCS/GCC/libexec/gcc/x86_64-centos-linux/9.2.0/lto-wrapper
Target: x86_64-centos-linux
Configured with: ../src/gcc-9.2.0/configure --prefix=/depot/gcc-9.2.0
--enable-bootstrap --enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,fortran --disable-libgcj --with-cpu=generic
--build=x86_64-centos-linux
Thread model: posix
gcc version 9.2.0 (GCC) 


Assembly Code
=============

0000000000002c10 <raceGetDistSelectInterval>:
    2c10:       4c 8d 54 24 08          lea    0x8(%rsp),%r10
    2c15:       48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
    2c19:       41 ff 72 f8             pushq  -0x8(%r10)
    2c1d:       55                      push   %rbp
=>  2c1e:       48 89 e5                mov    %rsp,%rbp
    2c21:       41 57                   push   %r15
    2c23:       41 56                   push   %r14
    2c25:       41 55                   push   %r13
    2c27:       41 54                   push   %r12
    2c29:       41 52                   push   %r10

Interrupt happened while on this instruction.

=>  2c1e:       48 89 e5                mov    %rsp,%rbp

Here (before executing this instruction), rbp is pointing to parent frame.

So, the following DWARF doesn't look quite right.

000006b0 0000000000000044 000006b4 FDE cie=00000000
pc=0000000000002c10..0000000000003607
  DW_CFA_advance_loc: 5 to 0000000000002c15
  DW_CFA_def_cfa: r10 (r10) ofs 0
  DW_CFA_advance_loc: 9 to 0000000000002c1e
  DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
  DW_CFA_advance_loc: 13 to 0000000000002c2b
  DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref)
  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: 9 to 0000000000002c1e
>>   DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)

Notice at address 0000000000002c1e, we are relying on rbp which is pointing to
the caller procedure's rbp, not the current procedure's rbp.


000006b0 0000000000000044 000006b4 FDE cie=00000000
pc=0000000000002c10..0000000000003607
   LOC           CFA      rbx   rbp   r12   r13   r14   r15   ra      
0000000000002c10 rsp+8    u     u     u     u     u     u     c-8   
0000000000002c15 r10+0    u     u     u     u     u     u     c-8   
0000000000002c1e r10+0    u     exp   u     u     u     u     c-8   
0000000000002c2b exp      u     exp   exp   exp   exp   exp   c-8   
0000000000002c2c exp      exp   exp   exp   exp   exp   exp   c-8   
0000000000002e16 r10+0    exp   exp   exp   exp   exp   exp   c-8   
0000000000002e23 rsp+8    exp   exp   exp   exp   exp   exp   c-8   
0000000000002e24 exp      exp   exp   exp   exp   exp   exp   c-8   


Actual GDB disassemble at the crash point:


Dump of assembler code for function raceGetDistSelectInterval:
   0x00002aaaafd63bd0 <+0>: lea    0x8(%rsp),%r10
   0x00002aaaafd63bd5 <+5>: and    $0xfffffffffffffff0,%rsp
   0x00002aaaafd63bd9 <+9>: pushq  -0x8(%r10)
   0x00002aaaafd63bdd <+13>:    push   %rbp
=> 0x00002aaaafd63bde <+14>:    mov    %rsp,%rbp
   0x00002aaaafd63be1 <+17>:    push   %r15
   0x00002aaaafd63be3 <+19>:    push   %r14


I will add the .i file in few days (have to take care of IP issues as per my
company guidelines).

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[aatsnps at gmail dot com]

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

--- Comment #5 from AJ D <aatsnps at gmail dot com> ---
Created attachment 50437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50437&action=edit
Function _func_with_dwarf_issue_ should demonstrate the issue

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[aatsnps at gmail dot com]

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

--- Comment #6 from AJ D <aatsnps at gmail dot com> ---
Test Case:
----------

typedef long int intptr_t;
typedef unsigned long int uintptr_t;
typedef intptr_t DummyType14;
typedef intptr_t DummyType8;
typedef struct DummyType15IntT DummyType15T;
typedef struct DummyType15IntT *DummyType15;
typedef struct DummyType13Struct DummyType13;
typedef struct DummyType10Struct DummyType10;
typedef struct DummyType4_struct DummyType4_struct;
typedef struct DummyType4_struct *DummyType4;
typedef struct DummyType4_struct DummyType6;
typedef struct DummyType1Struct DummyType1;
typedef struct DummyType2Struct DummyType2;
typedef struct DummyType12Struct DummyType12;
typedef double DummyType19;
extern int DummyType20;
extern int DummyType21;
extern int DummyType22;

struct DummyType13Struct {
    DummyType13 *dm1;
    void *dm2;
};

typedef struct DummyType9Struct {
    DummyType13 *dm1;
    DummyType13 *dm2;
    int dm3;
} DummyType9;

struct DummyType10Struct
{
};

struct DummyType4_struct {
    void *dm1;
    int dm2;
    int dm3;
    int dm4;
};

typedef struct DummyType5Struct {
} DummyType5;

typedef union DummyType18Union {
    DummyType12 *dm1;
    uintptr_t dm2;
} DummyType18;

struct DummyType1Struct {
    DummyType15 dm1;
    unsigned int dm2:1;
};

typedef struct DummyType3Struct {
    DummyType18 dm1;
} DummyType3;

typedef struct DummyType11Struct {
    DummyType10 *dm1;
    double dm2;
} DummyType11;

typedef struct DummyType17Struct {
    DummyType2 *dm1;
} DummyType17;

typedef struct DummyType7Struct {
    DummyType6 *dm1;
    DummyType17 *dm2;
} DummyType7;

typedef struct DummyType16Struct {
    DummyType12 *dm1;
} DummyType16;

extern int func1(DummyType15, DummyType14, DummyType8*);
extern int func2(DummyType2*);
extern const DummyType12 *func3(DummyType2*);
extern DummyType9 *func4(const DummyType12*);
extern DummyType13* func5(void);
extern DummyType9* func6(void);
extern int func7(int);
extern DummyType16 *func8(double, DummyType12*);

DummyType5 *_func_with_dwarf_issue_(DummyType1 *arg1,
                                    DummyType2 *arg2,
                                    DummyType3 **arg3,
                                    unsigned int *arg4,
                                    unsigned int *arg5,
                                    DummyType4 *arg6,
                                    DummyType4 *arg7) {
    DummyType6 *var1 = 0;
    DummyType7 *var2 = 0;
    DummyType8 var3 = 0;

    *arg3 = 0;
    if (arg1->dm1 &&
            func1((arg1->dm1), (DummyType14) (func2(arg2)), (DummyType8 *)
(&var3))

                              ) {
        var2 = (DummyType7 *)var3;
        if (var2) {
            DummyType9 *var4 = 0;
            DummyType9 *var5 = 0;
            DummyType5 *var6 = 0;
            DummyType10 *var7 = 0;
            DummyType11 *var8 = 0;
            int var9 = 0;
            DummyType12 *var10 = 
                                  ((void *)0)
                                      ;

            var1 = var2->dm1;
            var4 = func4(func3(arg2));
            { DummyType13 *var11; var11 = (var4)->dm1; while(var11){ var7 =
(DummyType10 *) var11->dm2; var11 = var11->dm1; {
                for (; var9 < ((var1)->dm2); var9++) {
                    var8 = (DummyType21 = (var9), (DummyType21 < 0 ||
DummyType21 >= (var1)->dm2) ? func7(0) : 0, sizeof(DummyType11 *) !=
(var1)->dm4 ? func7(1) : 0, ((DummyType11 * *)((var1)->dm1))[DummyType21]);
                    if (var8->dm1) {
                        if (var10 && var2->dm2->dm1 && arg1->dm2) {
                            var10 = 0;
                        }

                        if (var2->dm2->dm1 &&
                                !var10) {
                            if (!var5) {
                                var5 = func6();
                            }
                            { DummyType13 *var11; var11 = func5(); var11->dm2 =
(void *)(var6); if(!((var5)->dm2)){ (var5)->dm1 = var11; (var5)->dm2 = var11; }
else{ (var5)->dm2->dm1 = var11; (var5)->dm2 = var11; } (var5)->dm3++;
var11->dm1 = (DummyType13 *)0; };
                        }
                        else {
                            func8(var8->dm2,
                                                                      var10);
                        }
                    }
                }
            } } };
        }
    }
    return 0;
}


GCC Command Line:
----------------

gcc -DSTATIC_LIBRARY -DINST64_ENABLE -Xassembler -mrelax-relocations=no -m64
-msse2 -fPIC -DSTATIC_LIBRARY -D__NO_STRING_INLINES -mstackrealign
-DPEBLK_THREAD -DINST64_ENABLE -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 -o test.o -O3 -msse2
-fno-strict-aliasing -fPIC -fomit-frame-pointer -c test.i


GCC Version / Configuration
---------------------------

vg-centos72-vm01> gcc --version
gcc (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

vg-centos72-vm01> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/depot/qsc/QSCS/GCC/libexec/gcc/x86_64-centos-linux/9.2.0/lto-wrapper
Target: x86_64-centos-linux
Configured with: ../src/gcc-9.2.0/configure --prefix=/depot/gcc-9.2.0
--enable-bootstrap --enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,fortran --disable-libgcj --with-cpu=generic
--build=x86_64-centos-linux
Thread model: posix
gcc version 9.2.0 (GCC) 
vg-centos72-vm01> 



Generated Assembly
------------------

0000000000000000 <_func_with_dwarf_issue_>:
   0:   4c 8d 54 24 08          lea    0x8(%rsp),%r10
   5:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
   9:   41 ff 72 f8             pushq  -0x8(%r10)
   d:   55                      push   %rbp
-> e:   48 89 e5                mov    %rsp,%rbp
  11:   41 57                   push   %r15
  13:   41 56                   push   %r14
  15:   41 55                   push   %r13
  17:   41 54                   push   %r12
  19:   41 52                   push   %r10


Interrupted at the following instruction:

   e:   48 89 e5                mov    %rsp,%rbp

Generated DWARF
--------------
00000018 0000000000000044 0000001c FDE cie=00000000
pc=0000000000000000..000000000000018d
  DW_CFA_advance_loc: 5 to 0000000000000005
  DW_CFA_def_cfa: r10 (r10) ofs 0
  DW_CFA_advance_loc: 9 to 000000000000000e
  DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
  DW_CFA_advance_loc: 13 to 000000000000001b
  DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref)
  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)


Issue:
  DW_CFA_advance_loc: 9 to 000000000000000e
  DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)

At address 000000000000000e, %rbp is pointing to parent's stack frame, instead
of current stack frame.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
#c6 reproduces even on current trunk with
-fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing
-mstackrealign

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I wonder about:

--- gcc/dwarf2cfi.c.jj  2021-03-02 11:25:47.217727061 +0100
+++ gcc/dwarf2cfi.c     2021-03-23 17:34:58.240281522 +0100
@@ -2705,12 +2705,15 @@ scan_trace (dw_trace_info *trace, bool e
              dwarf2out_flush_queued_reg_saves ();
            }
          else if (!NONJUMP_INSN_P (insn)
-                  || clobbers_queued_reg_save (insn)
                   || find_reg_note (insn, REG_CFA_FLUSH_QUEUE, NULL))
            dwarf2out_flush_queued_reg_saves ();
          any_cfis_emitted = false;

          add_cfi_insn = insn;
+
+         if (queued_reg_saves.length () && clobbers_queued_reg_save (insn))
+           dwarf2out_flush_queued_reg_saves ();
+
          scan_insn_after (insn);
          control = insn;
        }

For calls or REG_CFA_FLUSH_QUEUE I can understand wanting to flush queued
register saves after the previous instruction, but for clobbers_queued_reg_save
cases I don't understand that.
This is about the:
pushq %rbp
movq %rsp, %rbp
case.  On pushq %rbp we queue the DW_CFA_expression for %rbp (but use %rbp in
the expression), then see clobbers_queued_reg_save (insn) on the movq %rsp,
%rbp
returning true because that instruction overwrites it.  But as it isn't really
a call, I believe at least the libgcc unwinder for async signals evaluates all
FDE instructions until the current pc inclusive.
pushq %rbp doesn't really change %rbp and CFA is computed from %r10 at that
point, and when we are at the start of movq %rsp, %rbp, we still haven't
changed %rbp.  As it is not a call, it doesn't have a separate byte abused for
in the middle of the instruction and so the only other possibility is after
that instruction.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As I said on the mailing list, the above patch has problems, it relies on the
insn that clobbers_queued_reg_save to be a single hardware instruction so that
a debug info consumer or unwinding can't stop "in the middle of the
instruction".
We have various NONJUMP_INSN_P insns that violate that, for one inline asm, but
also various patterns that emit more than one insn.
E.g. on x86 they are usually (but unsure if we can guarantee that) marked by
get_attr_type (insn) == TYPE_MULTI.
I have tried to instead deal with this on the i386.c side with:
--- i386.c.jj3  2021-03-25 21:05:35.554309579 +0100
+++ i386.c      2021-03-26 15:56:21.349642695 +0100
@@ -8355,9 +8355,33 @@ ix86_expand_prologue (void)

       if (m->fs.sp_offset == frame.hard_frame_pointer_offset)
        {
+         if (stack_realign_drap)
+           {
+             /* Pretend the push %[re]bp instruction is just
+                add $-wordsize, [%re]sp for CFI purposes.  */
+             rtx spadj = plus_constant (Pmode, stack_pointer_rtx,
+                                        -UNITS_PER_WORD);
+             rtx r = gen_rtx_SET (stack_pointer_rtx, spadj);
+             add_reg_note (insn, REG_FRAME_RELATED_EXPR, r);
+           }
+
          insn = emit_move_insn (hard_frame_pointer_rtx, stack_pointer_rtx);
          RTX_FRAME_RELATED_P (insn) = 1;

+         if (stack_realign_drap)
+           {
+             /* And that the mov %[re]sp, %[re]bp instruction acts as
+                both mov %[re]bp, (%[re]sp) and mov %[re]sp, %[re]bp
+                together for CFI purposes.  */
+             rtx r = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (2));
+             XVECEXP (r, 0, 0)
+               = gen_rtx_SET (gen_rtx_MEM (word_mode, stack_pointer_rtx),
+                              hard_frame_pointer_rtx);
+             XVECEXP (r, 0, 1)
+               = gen_rtx_SET (hard_frame_pointer_rtx, stack_pointer_rtx);
+             add_reg_note (insn, REG_FRAME_RELATED_EXPR, r);
+           }
+
          if (m->fs.cfa_reg == stack_pointer_rtx)
            m->fs.cfa_reg = hard_frame_pointer_rtx;
          m->fs.fp_offset = m->fs.sp_offset;
but unfortunately that doesn't work properly, because dwarf2cfi.c has special
rule for that push %[re]bp with drap active, described as Rule 18.
So I think we should instead change the dwarf2cfi.c rule 18 handling so that it
waits with the reg save until the hfp = sp instruction after it.

Generally, there is also the option of e.g. adding some insn attribute on
targets that want it which would say which instructions are single undivisible
hw instructions and use that get_attr_{single,undivisible} or how it would be
called in dwarf2cfi.c to decide whether to emit queued reg saves before it or
after it.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1cdfc98a9981768c475fabf069ba4d3e460deb2a

commit r11-7870-g1cdfc98a9981768c475fabf069ba4d3e460deb2a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 27 00:20:42 2021 +0100

    dwarf2cfi: Defer queued register saves some more [PR99334]

    On the testcase in the PR with
    -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing
-mstackrealign
    we have prologue:
    0000000000000000 <_func_with_dwarf_issue_>:
       0:   4c 8d 54 24 08          lea    0x8(%rsp),%r10
       5:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
       9:   41 ff 72 f8             pushq  -0x8(%r10)
       d:   55                      push   %rbp
       e:   48 89 e5                mov    %rsp,%rbp
      11:   41 57                   push   %r15
      13:   41 56                   push   %r14
      15:   41 55                   push   %r13
      17:   41 54                   push   %r12
      19:   41 52                   push   %r10
      1b:   53                      push   %rbx
      1c:   48 83 ec 20             sub    $0x20,%rsp
    and emit
    00000000 0000000000000014 00000000 CIE
      Version:               1
      Augmentation:          "zR"
      Code alignment factor: 1
      Data alignment factor: -8
      Return address column: 16
      Augmentation data:     1b
      DW_CFA_def_cfa: r7 (rsp) ofs 8
      DW_CFA_offset: r16 (rip) at cfa-8
      DW_CFA_nop
      DW_CFA_nop

    00000018 0000000000000044 0000001c FDE cie=00000000
pc=0000000000000000..00000000000001d5
      DW_CFA_advance_loc: 5 to 0000000000000005
      DW_CFA_def_cfa: r10 (r10) ofs 0
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 13 to 000000000000001b
      DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref)
      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)
    ...
    unwind info for that.  The problem is when async signal
    (or stepping through in the debugger) stops after the pushq %rbp
    instruction and before movq %rsp, %rbp, the unwind info says that
    caller's %rbp is saved there at *%rbp, but that is not true, caller's
    %rbp is either still available in the %rbp register, or in *%rsp,
    only after executing the next instruction - movq %rsp, %rbp - the
    location for %rbp is correct.  So, either we'd need to temporarily
    say:
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg7 (rsp): 0)
      DW_CFA_advance_loc: 3 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b
    or to me it seems more compact to just say:
      DW_CFA_advance_loc: 12 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b

    I've tried instead to deal with it through REG_FRAME_RELATED_EXPR
    from the backend, but that failed miserably as explained in the PR,
    dwarf2cfi.c has some rules (Rule 16 to Rule 19) that are specific to the
    dynamic stack realignment using drap register that only the i386 backend
    does right now, and by using REG_FRAME_RELATED_EXPR or REG_CFA* notes we
    can't emulate those rules.  The following patch instead does the deferring
    of the hard frame pointer save rule in dwarf2cfi.c Rule 18 handling and
    emits it on the (set hfp sp) assignment that must appear shortly after it
    and adds assertion that it is the case.

    The difference before/after the patch on the assembly is:
    --- pr99334.s~  2021-03-26 15:42:40.881749380 +0100
    +++ pr99334.s   2021-03-26 17:38:05.729161910 +0100
    @@ -11,8 +11,8 @@ _func_with_dwarf_issue_:
            andq    $-16, %rsp
            pushq   -8(%r10)
            pushq   %rbp
    -       .cfi_escape 0x10,0x6,0x2,0x76,0
            movq    %rsp, %rbp
    +       .cfi_escape 0x10,0x6,0x2,0x76,0
            pushq   %r15
            pushq   %r14
            pushq   %r13
    i.e. does just what we IMHO need, after pushq %rbp %rbp
    still contains parent's frame value and so the save rule doesn't
    need to be overridden there, ditto at the start of the next insn
    before the side-effect took effect, and we override it only after
    it when %rbp already has the right value.

    If some other target adds dynamic stack realignment in the future and
    the offset 0 case wouldn't be true there, the code can be adjusted so that
    it works on all the drap architectures, I'm pretty sure the code would
    need other adjustments too.

    For the rule 18 and for the (set hfp sp) after it we already have asserts
    for the drap cases that check whether the code looks the way i?86/x86_64
    emit it currently.

    2021-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR debug/99334
            * dwarf2out.h (struct dw_fde_node): Add rule18 member.
            * dwarf2cfi.c (dwarf2out_frame_debug_expr): When handling (set hfp
sp)
            assignment with drap_reg active, queue reg save for hfp with offset
0
            and flush queued reg saves.  When handling a push with rule18,
            defer queueing reg save for hfp and just assert the offset is 0.
            (scan_trace): Assert that fde->rule18 is false.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:f5df18504c1790413f293bfb50d40faa7f1ea860

commit r10-9624-gf5df18504c1790413f293bfb50d40faa7f1ea860
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 27 00:20:42 2021 +0100

    dwarf2cfi: Defer queued register saves some more [PR99334]

    On the testcase in the PR with
    -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing
-mstackrealign
    we have prologue:
    0000000000000000 <_func_with_dwarf_issue_>:
       0:   4c 8d 54 24 08          lea    0x8(%rsp),%r10
       5:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
       9:   41 ff 72 f8             pushq  -0x8(%r10)
       d:   55                      push   %rbp
       e:   48 89 e5                mov    %rsp,%rbp
      11:   41 57                   push   %r15
      13:   41 56                   push   %r14
      15:   41 55                   push   %r13
      17:   41 54                   push   %r12
      19:   41 52                   push   %r10
      1b:   53                      push   %rbx
      1c:   48 83 ec 20             sub    $0x20,%rsp
    and emit
    00000000 0000000000000014 00000000 CIE
      Version:               1
      Augmentation:          "zR"
      Code alignment factor: 1
      Data alignment factor: -8
      Return address column: 16
      Augmentation data:     1b
      DW_CFA_def_cfa: r7 (rsp) ofs 8
      DW_CFA_offset: r16 (rip) at cfa-8
      DW_CFA_nop
      DW_CFA_nop

    00000018 0000000000000044 0000001c FDE cie=00000000
pc=0000000000000000..00000000000001d5
      DW_CFA_advance_loc: 5 to 0000000000000005
      DW_CFA_def_cfa: r10 (r10) ofs 0
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 13 to 000000000000001b
      DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref)
      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)
    ...
    unwind info for that.  The problem is when async signal
    (or stepping through in the debugger) stops after the pushq %rbp
    instruction and before movq %rsp, %rbp, the unwind info says that
    caller's %rbp is saved there at *%rbp, but that is not true, caller's
    %rbp is either still available in the %rbp register, or in *%rsp,
    only after executing the next instruction - movq %rsp, %rbp - the
    location for %rbp is correct.  So, either we'd need to temporarily
    say:
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg7 (rsp): 0)
      DW_CFA_advance_loc: 3 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b
    or to me it seems more compact to just say:
      DW_CFA_advance_loc: 12 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b

    I've tried instead to deal with it through REG_FRAME_RELATED_EXPR
    from the backend, but that failed miserably as explained in the PR,
    dwarf2cfi.c has some rules (Rule 16 to Rule 19) that are specific to the
    dynamic stack realignment using drap register that only the i386 backend
    does right now, and by using REG_FRAME_RELATED_EXPR or REG_CFA* notes we
    can't emulate those rules.  The following patch instead does the deferring
    of the hard frame pointer save rule in dwarf2cfi.c Rule 18 handling and
    emits it on the (set hfp sp) assignment that must appear shortly after it
    and adds assertion that it is the case.

    The difference before/after the patch on the assembly is:
    --- pr99334.s~  2021-03-26 15:42:40.881749380 +0100
    +++ pr99334.s   2021-03-26 17:38:05.729161910 +0100
    @@ -11,8 +11,8 @@ _func_with_dwarf_issue_:
            andq    $-16, %rsp
            pushq   -8(%r10)
            pushq   %rbp
    -       .cfi_escape 0x10,0x6,0x2,0x76,0
            movq    %rsp, %rbp
    +       .cfi_escape 0x10,0x6,0x2,0x76,0
            pushq   %r15
            pushq   %r14
            pushq   %r13
    i.e. does just what we IMHO need, after pushq %rbp %rbp
    still contains parent's frame value and so the save rule doesn't
    need to be overridden there, ditto at the start of the next insn
    before the side-effect took effect, and we override it only after
    it when %rbp already has the right value.

    If some other target adds dynamic stack realignment in the future and
    the offset 0 case wouldn't be true there, the code can be adjusted so that
    it works on all the drap architectures, I'm pretty sure the code would
    need other adjustments too.

    For the rule 18 and for the (set hfp sp) after it we already have asserts
    for the drap cases that check whether the code looks the way i?86/x86_64
    emit it currently.

    2021-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR debug/99334
            * dwarf2out.h (struct dw_fde_node): Add rule18 member.
            * dwarf2cfi.c (dwarf2out_frame_debug_expr): When handling (set hfp
sp)
            assignment with drap_reg active, queue reg save for hfp with offset
0
            and flush queued reg saves.  When handling a push with rule18,
            defer queueing reg save for hfp and just assert the offset is 0.
            (scan_trace): Assert that fde->rule18 is false.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:c1780b4c6f1c0e91f10d13e70eb17f5d77f22bb0

commit r9-9438-gc1780b4c6f1c0e91f10d13e70eb17f5d77f22bb0
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 27 00:20:42 2021 +0100

    dwarf2cfi: Defer queued register saves some more [PR99334]

    On the testcase in the PR with
    -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing
-mstackrealign
    we have prologue:
    0000000000000000 <_func_with_dwarf_issue_>:
       0:   4c 8d 54 24 08          lea    0x8(%rsp),%r10
       5:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
       9:   41 ff 72 f8             pushq  -0x8(%r10)
       d:   55                      push   %rbp
       e:   48 89 e5                mov    %rsp,%rbp
      11:   41 57                   push   %r15
      13:   41 56                   push   %r14
      15:   41 55                   push   %r13
      17:   41 54                   push   %r12
      19:   41 52                   push   %r10
      1b:   53                      push   %rbx
      1c:   48 83 ec 20             sub    $0x20,%rsp
    and emit
    00000000 0000000000000014 00000000 CIE
      Version:               1
      Augmentation:          "zR"
      Code alignment factor: 1
      Data alignment factor: -8
      Return address column: 16
      Augmentation data:     1b
      DW_CFA_def_cfa: r7 (rsp) ofs 8
      DW_CFA_offset: r16 (rip) at cfa-8
      DW_CFA_nop
      DW_CFA_nop

    00000018 0000000000000044 0000001c FDE cie=00000000
pc=0000000000000000..00000000000001d5
      DW_CFA_advance_loc: 5 to 0000000000000005
      DW_CFA_def_cfa: r10 (r10) ofs 0
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 13 to 000000000000001b
      DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref)
      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)
    ...
    unwind info for that.  The problem is when async signal
    (or stepping through in the debugger) stops after the pushq %rbp
    instruction and before movq %rsp, %rbp, the unwind info says that
    caller's %rbp is saved there at *%rbp, but that is not true, caller's
    %rbp is either still available in the %rbp register, or in *%rsp,
    only after executing the next instruction - movq %rsp, %rbp - the
    location for %rbp is correct.  So, either we'd need to temporarily
    say:
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg7 (rsp): 0)
      DW_CFA_advance_loc: 3 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b
    or to me it seems more compact to just say:
      DW_CFA_advance_loc: 12 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b

    I've tried instead to deal with it through REG_FRAME_RELATED_EXPR
    from the backend, but that failed miserably as explained in the PR,
    dwarf2cfi.c has some rules (Rule 16 to Rule 19) that are specific to the
    dynamic stack realignment using drap register that only the i386 backend
    does right now, and by using REG_FRAME_RELATED_EXPR or REG_CFA* notes we
    can't emulate those rules.  The following patch instead does the deferring
    of the hard frame pointer save rule in dwarf2cfi.c Rule 18 handling and
    emits it on the (set hfp sp) assignment that must appear shortly after it
    and adds assertion that it is the case.

    The difference before/after the patch on the assembly is:
    --- pr99334.s~  2021-03-26 15:42:40.881749380 +0100
    +++ pr99334.s   2021-03-26 17:38:05.729161910 +0100
    @@ -11,8 +11,8 @@ _func_with_dwarf_issue_:
            andq    $-16, %rsp
            pushq   -8(%r10)
            pushq   %rbp
    -       .cfi_escape 0x10,0x6,0x2,0x76,0
            movq    %rsp, %rbp
    +       .cfi_escape 0x10,0x6,0x2,0x76,0
            pushq   %r15
            pushq   %r14
            pushq   %r13
    i.e. does just what we IMHO need, after pushq %rbp %rbp
    still contains parent's frame value and so the save rule doesn't
    need to be overridden there, ditto at the start of the next insn
    before the side-effect took effect, and we override it only after
    it when %rbp already has the right value.

    If some other target adds dynamic stack realignment in the future and
    the offset 0 case wouldn't be true there, the code can be adjusted so that
    it works on all the drap architectures, I'm pretty sure the code would
    need other adjustments too.

    For the rule 18 and for the (set hfp sp) after it we already have asserts
    for the drap cases that check whether the code looks the way i?86/x86_64
    emit it currently.

    2021-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR debug/99334
            * dwarf2out.h (struct dw_fde_node): Add rule18 member.
            * dwarf2cfi.c (dwarf2out_frame_debug_expr): When handling (set hfp
sp)
            assignment with drap_reg active, queue reg save for hfp with offset
0
            and flush queued reg saves.  When handling a push with rule18,
            defer queueing reg save for hfp and just assert the offset is 0.
            (scan_trace): Assert that fde->rule18 is false.

    (cherry picked from commit f5df18504c1790413f293bfb50d40faa7f1ea860)

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:698b03a66e5115c5dd5cf84bbb499e210df3e709

commit r8-10901-g698b03a66e5115c5dd5cf84bbb499e210df3e709
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Sat Mar 27 00:20:42 2021 +0100

    dwarf2cfi: Defer queued register saves some more [PR99334]

    On the testcase in the PR with
    -fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing
-mstackrealign
    we have prologue:
    0000000000000000 <_func_with_dwarf_issue_>:
       0:   4c 8d 54 24 08          lea    0x8(%rsp),%r10
       5:   48 83 e4 f0             and    $0xfffffffffffffff0,%rsp
       9:   41 ff 72 f8             pushq  -0x8(%r10)
       d:   55                      push   %rbp
       e:   48 89 e5                mov    %rsp,%rbp
      11:   41 57                   push   %r15
      13:   41 56                   push   %r14
      15:   41 55                   push   %r13
      17:   41 54                   push   %r12
      19:   41 52                   push   %r10
      1b:   53                      push   %rbx
      1c:   48 83 ec 20             sub    $0x20,%rsp
    and emit
    00000000 0000000000000014 00000000 CIE
      Version:               1
      Augmentation:          "zR"
      Code alignment factor: 1
      Data alignment factor: -8
      Return address column: 16
      Augmentation data:     1b
      DW_CFA_def_cfa: r7 (rsp) ofs 8
      DW_CFA_offset: r16 (rip) at cfa-8
      DW_CFA_nop
      DW_CFA_nop

    00000018 0000000000000044 0000001c FDE cie=00000000
pc=0000000000000000..00000000000001d5
      DW_CFA_advance_loc: 5 to 0000000000000005
      DW_CFA_def_cfa: r10 (r10) ofs 0
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 13 to 000000000000001b
      DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -40; DW_OP_deref)
      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)
    ...
    unwind info for that.  The problem is when async signal
    (or stepping through in the debugger) stops after the pushq %rbp
    instruction and before movq %rsp, %rbp, the unwind info says that
    caller's %rbp is saved there at *%rbp, but that is not true, caller's
    %rbp is either still available in the %rbp register, or in *%rsp,
    only after executing the next instruction - movq %rsp, %rbp - the
    location for %rbp is correct.  So, either we'd need to temporarily
    say:
      DW_CFA_advance_loc: 9 to 000000000000000e
      DW_CFA_expression: r6 (rbp) (DW_OP_breg7 (rsp): 0)
      DW_CFA_advance_loc: 3 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b
    or to me it seems more compact to just say:
      DW_CFA_advance_loc: 12 to 0000000000000011
      DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
      DW_CFA_advance_loc: 10 to 000000000000001b

    I've tried instead to deal with it through REG_FRAME_RELATED_EXPR
    from the backend, but that failed miserably as explained in the PR,
    dwarf2cfi.c has some rules (Rule 16 to Rule 19) that are specific to the
    dynamic stack realignment using drap register that only the i386 backend
    does right now, and by using REG_FRAME_RELATED_EXPR or REG_CFA* notes we
    can't emulate those rules.  The following patch instead does the deferring
    of the hard frame pointer save rule in dwarf2cfi.c Rule 18 handling and
    emits it on the (set hfp sp) assignment that must appear shortly after it
    and adds assertion that it is the case.

    The difference before/after the patch on the assembly is:
    --- pr99334.s~  2021-03-26 15:42:40.881749380 +0100
    +++ pr99334.s   2021-03-26 17:38:05.729161910 +0100
    @@ -11,8 +11,8 @@ _func_with_dwarf_issue_:
            andq    $-16, %rsp
            pushq   -8(%r10)
            pushq   %rbp
    -       .cfi_escape 0x10,0x6,0x2,0x76,0
            movq    %rsp, %rbp
    +       .cfi_escape 0x10,0x6,0x2,0x76,0
            pushq   %r15
            pushq   %r14
            pushq   %r13
    i.e. does just what we IMHO need, after pushq %rbp %rbp
    still contains parent's frame value and so the save rule doesn't
    need to be overridden there, ditto at the start of the next insn
    before the side-effect took effect, and we override it only after
    it when %rbp already has the right value.

    If some other target adds dynamic stack realignment in the future and
    the offset 0 case wouldn't be true there, the code can be adjusted so that
    it works on all the drap architectures, I'm pretty sure the code would
    need other adjustments too.

    For the rule 18 and for the (set hfp sp) after it we already have asserts
    for the drap cases that check whether the code looks the way i?86/x86_64
    emit it currently.

    2021-03-26  Jakub Jelinek  <jakub@redhat.com>

            PR debug/99334
            * dwarf2out.h (struct dw_fde_node): Add rule18 member.
            * dwarf2cfi.c (dwarf2out_frame_debug_expr): When handling (set hfp
sp)
            assignment with drap_reg active, queue reg save for hfp with offset
0
            and flush queued reg saves.  When handling a push with rule18,
            defer queueing reg save for hfp and just assert the offset is 0.
            (scan_trace): Assert that fde->rule18 is false.

    (cherry picked from commit f5df18504c1790413f293bfb50d40faa7f1ea860)

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[aatsnps at gmail dot com]

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

--- Comment #15 from AJ D <aatsnps at gmail dot com> ---
Is it fixed in GCC-9.4?  

Didn't find PR99334 in
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.4

If not, which GCC9.* release can we expect a fix for it?

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |10.3.0, 11.1.0, 8.5.0,
                   |                            |9.4.0
   Target Milestone|8.2                         |8.5

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[pinskia at gcc dot gnu.org]

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

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to AJ D from comment #15)
> Is it fixed in GCC-9.4?  
> 
> Didn't find PR99334 in
> https://gcc.gnu.org/bugzilla/buglist.
> cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.4
> 
> If not, which GCC9.* release can we expect a fix for it?

So the target milestone only says the earliest GCC version where it is fixed. 
I updated the "known to work" field on which release the patch in comment #10,
#11, #12, and #13 were committed to.  Also updated the target milestone to the
correct one.