* [Bug c/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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 ` jakub at gcc dot gnu.org
2021-03-02 7:47 ` [Bug debug/99334] " rguenth at gcc dot gnu.org
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-01 22:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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 ` rguenth at gcc dot gnu.org
2021-03-08 21:53 ` aatsnps at gmail dot com
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-02 7:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: aatsnps at gmail dot com @ 2021-03-08 21:53 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (2 preceding siblings ...)
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
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-03-08 22:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (3 preceding siblings ...)
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
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: aatsnps at gmail dot com @ 2021-03-19 19:18 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (4 preceding siblings ...)
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
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: aatsnps at gmail dot com @ 2021-03-20 4:39 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (5 preceding siblings ...)
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
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: aatsnps at gmail dot com @ 2021-03-20 4:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (6 preceding siblings ...)
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
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-20 9:39 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (7 preceding siblings ...)
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
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-23 17:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (8 preceding siblings ...)
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
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-26 16:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (9 preceding siblings ...)
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
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-26 23:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (10 preceding siblings ...)
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
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-30 22:41 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (11 preceding siblings ...)
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
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-20 23:34 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (12 preceding siblings ...)
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
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-22 16:52 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (13 preceding siblings ...)
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
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-22 17:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (14 preceding siblings ...)
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
17 siblings, 0 replies; 19+ messages in thread
From: aatsnps at gmail dot com @ 2021-09-22 4:06 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (15 preceding siblings ...)
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
17 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-22 5:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame
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
` (16 preceding siblings ...)
2021-09-22 5:19 ` pinskia at gcc dot gnu.org
@ 2021-09-22 5:22 ` pinskia at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-22 5:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread