* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
@ 2024-02-26 14:56 ` jakub at gcc dot gnu.org
2024-02-26 15:10 ` jakub at gcc dot gnu.org
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-26 14:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
Priority|P3 |P1
Target Milestone|--- |14.0
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
2024-02-26 14:56 ` [Bug target/114116] " jakub at gcc dot gnu.org
@ 2024-02-26 15:10 ` jakub at gcc dot gnu.org
2024-02-26 15:34 ` hjl.tools at gmail dot com
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-26 15:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Maybe introduce TYPE_NO_CALLEE_SAVED_REGISTERS_EXCEPT_BP or something similar?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
2024-02-26 14:56 ` [Bug target/114116] " jakub at gcc dot gnu.org
2024-02-26 15:10 ` jakub at gcc dot gnu.org
@ 2024-02-26 15:34 ` hjl.tools at gmail dot com
2024-02-26 16:29 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2024-02-26 15:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-02-26
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2024-02-26 15:34 ` hjl.tools at gmail dot com
@ 2024-02-26 16:29 ` jakub at gcc dot gnu.org
2024-02-26 16:37 ` hjl.tools at gmail dot com
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-26 16:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57545&action=edit
gcc14-pr114116.patch
This seems to fix it, so far tested just on the small testcase, back to the
expected backtrace there.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2024-02-26 16:29 ` jakub at gcc dot gnu.org
@ 2024-02-26 16:37 ` hjl.tools at gmail dot com
2024-02-26 16:38 ` pinskia at gcc dot gnu.org
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2024-02-26 16:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 57545 [details]
> gcc14-pr114116.patch
>
> This seems to fix it, so far tested just on the small testcase, back to the
> expected backtrace there.
Should we check -g? Without -g, I don't think we need to save FP.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2024-02-26 16:37 ` hjl.tools at gmail dot com
@ 2024-02-26 16:38 ` pinskia at gcc dot gnu.org
2024-02-26 16:41 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-02-26 16:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Created attachment 57545 [details]
> > gcc14-pr114116.patch
> >
> > This seems to fix it, so far tested just on the small testcase, back to the
> > expected backtrace there.
>
> Should we check -g? Without -g, I don't think we need to save FP.
NO, the code generated with -g should be the same as without ...
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2024-02-26 16:38 ` pinskia at gcc dot gnu.org
@ 2024-02-26 16:41 ` jakub at gcc dot gnu.org
2024-02-26 17:48 ` hjl.tools at gmail dot com
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-02-26 16:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah. Not to mention, one can call backtrace even if -g0; you just don't get
nice names for the addresses. Without the patch you get crashes in the
unwinder when doing backtrace.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2024-02-26 16:41 ` jakub at gcc dot gnu.org
@ 2024-02-26 17:48 ` hjl.tools at gmail dot com
2024-02-29 13:58 ` lukas.graetz@tu-darmstadt.de
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2024-02-26 17:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|hjl.tools at gmail dot com |unassigned at gcc dot gnu.org
--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #5)
> Yeah. Not to mention, one can call backtrace even if -g0; you just don't
> get nice names for the addresses. Without the patch you get crashes in the
> unwinder when doing backtrace.
Should we generate REG_CFA_UNDEFINED for unsaved callee-saved registers to
help unwinder:
https://patchwork.sourceware.org/project/gcc/list/?series=30327
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2024-02-26 17:48 ` hjl.tools at gmail dot com
@ 2024-02-29 13:58 ` lukas.graetz@tu-darmstadt.de
2024-02-29 14:21 ` hjl.tools at gmail dot com
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: lukas.graetz@tu-darmstadt.de @ 2024-02-29 13:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
Lukas Grätz <lukas.graetz@tu-darmstadt.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lukas.graetz@tu-darmstadt.d
| |e
--- Comment #7 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to H.J. Lu from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Yeah. Not to mention, one can call backtrace even if -g0; you just don't
> > get nice names for the addresses. Without the patch you get crashes in the
> > unwinder when doing backtrace.
>
> Should we generate REG_CFA_UNDEFINED for unsaved callee-saved registers to
> help unwinder:
>
> https://patchwork.sourceware.org/project/gcc/list/?series=30327
Yes. Also for gdb this is needed.
Perhaps I did something wrong. On my computer, I could get the first patch
working to save rbp, I also applied the patch which should omit the
.cfi_undefined. But somehow, I still not get .cfi_undefined for any of the
examples.
$ ./gcc/host-x86_64-pc-linux-gnu/gcc/cc1 -O3
gcc/gcc/testsuite/gcc.target/i386/pr38534-7.c -o pr38534-7.S
$ cat pr38534-7.S
[...]
no_return_to_caller:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movl $array+67108860, %eax
xorl %r13d, %r13d
[...]
The ".cfi_undefined 13" is still missing...
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2024-02-29 13:58 ` lukas.graetz@tu-darmstadt.de
@ 2024-02-29 14:21 ` hjl.tools at gmail dot com
2024-02-29 14:31 ` lukas.graetz@tu-darmstadt.de
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2024-02-29 14:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Lukas Grätz from comment #7)
> (In reply to H.J. Lu from comment #6)
> > (In reply to Jakub Jelinek from comment #5)
> > > Yeah. Not to mention, one can call backtrace even if -g0; you just don't
> > > get nice names for the addresses. Without the patch you get crashes in the
> > > unwinder when doing backtrace.
> >
> > Should we generate REG_CFA_UNDEFINED for unsaved callee-saved registers to
> > help unwinder:
> >
> > https://patchwork.sourceware.org/project/gcc/list/?series=30327
>
> Yes. Also for gdb this is needed.
>
> Perhaps I did something wrong. On my computer, I could get the first patch
> working to save rbp, I also applied the patch which should omit the
> .cfi_undefined. But somehow, I still not get .cfi_undefined for any of the
> examples.
>
>
> $ ./gcc/host-x86_64-pc-linux-gnu/gcc/cc1 -O3
> gcc/gcc/testsuite/gcc.target/i386/pr38534-7.c -o pr38534-7.S
>
> $ cat pr38534-7.S
> [...]
> no_return_to_caller:
> .LFB0:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movl $array+67108860, %eax
> xorl %r13d, %r13d
> [...]
>
>
> The ".cfi_undefined 13" is still missing...
It is generated only when -g is used.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (9 preceding siblings ...)
2024-02-29 14:21 ` hjl.tools at gmail dot com
@ 2024-02-29 14:31 ` lukas.graetz@tu-darmstadt.de
2024-02-29 14:32 ` hjl.tools at gmail dot com
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: lukas.graetz@tu-darmstadt.de @ 2024-02-29 14:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #9 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to H.J. Lu from comment #8)
> (In reply to Lukas Grätz from comment #7)
> > (In reply to H.J. Lu from comment #6)
> > > (In reply to Jakub Jelinek from comment #5)
> > > > Yeah. Not to mention, one can call backtrace even if -g0; you just don't
> > > > get nice names for the addresses. Without the patch you get crashes in the
> > > > unwinder when doing backtrace.
> > >
> > > Should we generate REG_CFA_UNDEFINED for unsaved callee-saved registers to
> > > help unwinder:
> > >
> > > https://patchwork.sourceware.org/project/gcc/list/?series=30327
> >
> > Yes. Also for gdb this is needed.
> >
> > Perhaps I did something wrong. On my computer, I could get the first patch
> > working to save rbp, I also applied the patch which should omit the
> > .cfi_undefined. But somehow, I still not get .cfi_undefined for any of the
> > examples.
> >
> >
> > $ ./gcc/host-x86_64-pc-linux-gnu/gcc/cc1 -O3
> > gcc/gcc/testsuite/gcc.target/i386/pr38534-7.c -o pr38534-7.S
> >
> > $ cat pr38534-7.S
> > [...]
> > no_return_to_caller:
> > .LFB0:
> > .cfi_startproc
> > pushq %rbp
> > .cfi_def_cfa_offset 16
> > .cfi_offset 6, -16
> > movl $array+67108860, %eax
> > xorl %r13d, %r13d
> > [...]
> >
> >
> > The ".cfi_undefined 13" is still missing...
>
> It is generated only when -g is used.
Not on my computer. When I used -g I got:
no_return_to_caller:
.LFB0:
.loc 1 16 1 view -0
.cfi_startproc
.loc 1 17 3 view .LVU1
.loc 1 18 3 view .LVU2
.LVL0:
.loc 1 18 26 discriminator 1 view .LVU3
.loc 1 16 1 is_stmt 0 view .LVU4
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movl $array+67108860, %eax
.loc 1 21 31 view .LVU5
xorl %r13d, %r13d
.loc 1 16 1 view .LVU6
Still no .cfi_undefined 13. In principle, it should also be generated without
-g, as the rest of .cfi_offset and friends.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (10 preceding siblings ...)
2024-02-29 14:31 ` lukas.graetz@tu-darmstadt.de
@ 2024-02-29 14:32 ` hjl.tools at gmail dot com
2024-02-29 14:42 ` lukas.graetz@tu-darmstadt.de
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2024-02-29 14:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Lukas Grätz from comment #9)
>
> Not on my computer. When I used -g I got:
>
>
> no_return_to_caller:
> .LFB0:
> .loc 1 16 1 view -0
> .cfi_startproc
> .loc 1 17 3 view .LVU1
> .loc 1 18 3 view .LVU2
> .LVL0:
> .loc 1 18 26 discriminator 1 view .LVU3
> .loc 1 16 1 is_stmt 0 view .LVU4
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movl $array+67108860, %eax
> .loc 1 21 31 view .LVU5
> xorl %r13d, %r13d
> .loc 1 16 1 view .LVU6
>
>
> Still no .cfi_undefined 13. In principle, it should also be generated
> without -g, as the rest of .cfi_offset and friends.
Did you apply my patch? I got
.globl no_return_to_caller
.type no_return_to_caller, @function
no_return_to_caller:
.LFB0:
.file 1 "pr38534-1.c"
.loc 1 16 1 view -0
.cfi_startproc
.loc 1 17 3 view .LVU1
.loc 1 18 3 view .LVU2
.LVL0:
.loc 1 18 26 discriminator 1 view .LVU3
.loc 1 16 1 is_stmt 0 view .LVU4
subq $24, %rsp
.cfi_undefined 15
.cfi_undefined 14
.cfi_undefined 13
.cfi_undefined 12
.cfi_undefined 6
...
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (11 preceding siblings ...)
2024-02-29 14:32 ` hjl.tools at gmail dot com
@ 2024-02-29 14:42 ` lukas.graetz@tu-darmstadt.de
2024-02-29 14:43 ` hjl.tools at gmail dot com
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: lukas.graetz@tu-darmstadt.de @ 2024-02-29 14:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #11 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to H.J. Lu from comment #10)
> (In reply to Lukas Grätz from comment #9)
>
> >
> > Not on my computer. When I used -g I got:
> >
> >
> > no_return_to_caller:
> > .LFB0:
> > .loc 1 16 1 view -0
> > .cfi_startproc
> > .loc 1 17 3 view .LVU1
> > .loc 1 18 3 view .LVU2
> > .LVL0:
> > .loc 1 18 26 discriminator 1 view .LVU3
> > .loc 1 16 1 is_stmt 0 view .LVU4
> > pushq %rbp
> > .cfi_def_cfa_offset 16
> > .cfi_offset 6, -16
> > movl $array+67108860, %eax
> > .loc 1 21 31 view .LVU5
> > xorl %r13d, %r13d
> > .loc 1 16 1 view .LVU6
> >
> >
> > Still no .cfi_undefined 13. In principle, it should also be generated
> > without -g, as the rest of .cfi_offset and friends.
>
> Did you apply my patch? I got
>
> .globl no_return_to_caller
> .type no_return_to_caller, @function
> no_return_to_caller:
> .LFB0:
> .file 1 "pr38534-1.c"
> .loc 1 16 1 view -0
> .cfi_startproc
> .loc 1 17 3 view .LVU1
> .loc 1 18 3 view .LVU2
> .LVL0:
> .loc 1 18 26 discriminator 1 view .LVU3
> .loc 1 16 1 is_stmt 0 view .LVU4
> subq $24, %rsp
> .cfi_undefined 15
> .cfi_undefined 14
> .cfi_undefined 13
> .cfi_undefined 12
> .cfi_undefined 6
> ...
I applied it, double checked, make distclean, configure, make again.
But your result seems different. Have you applied Jakub Jelinek's patch to save
%rbp? I applied both patches. Perhaps there was some subtle merge-conflict with
the two patches.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (12 preceding siblings ...)
2024-02-29 14:42 ` lukas.graetz@tu-darmstadt.de
@ 2024-02-29 14:43 ` hjl.tools at gmail dot com
2024-03-01 4:39 ` lukas.graetz@tu-darmstadt.de
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: hjl.tools at gmail dot com @ 2024-02-29 14:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Lukas Grätz from comment #11)
>
> I applied it, double checked, make distclean, configure, make again.
>
> But your result seems different. Have you applied Jakub Jelinek's patch to
No.
> save %rbp? I applied both patches. Perhaps there was some subtle
> merge-conflict with the two patches.
Please try just my patch.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (13 preceding siblings ...)
2024-02-29 14:43 ` hjl.tools at gmail dot com
@ 2024-03-01 4:39 ` lukas.graetz@tu-darmstadt.de
2024-03-01 6:44 ` lukas.graetz@tu-darmstadt.de
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: lukas.graetz@tu-darmstadt.de @ 2024-03-01 4:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #13 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to H.J. Lu from comment #12)
> (In reply to Lukas Grätz from comment #11)
> >
> > I applied it, double checked, make distclean, configure, make again.
> >
> > But your result seems different. Have you applied Jakub Jelinek's patch to
>
> No.
>
> > save %rbp? I applied both patches. Perhaps there was some subtle
> > merge-conflict with the two patches.
>
> Please try just my patch.
Thanks, that worked!
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (14 preceding siblings ...)
2024-03-01 4:39 ` lukas.graetz@tu-darmstadt.de
@ 2024-03-01 6:44 ` lukas.graetz@tu-darmstadt.de
2024-03-05 9:26 ` cvs-commit at gcc dot gnu.org
2024-03-05 9:43 ` jakub at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: lukas.graetz@tu-darmstadt.de @ 2024-03-01 6:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #14 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 57545 [details]
> gcc14-pr114116.patch
>
> This seems to fix it, so far tested just on the small testcase, back to the
> expected backtrace there.
As I said in PR 38534, comment [1], the rsp could be saved to rbp due to an
unknown-sized stack-frame:
movq %rsp, %rbp
.cfi_def_cfa_register 6
Therefore, if we want the backtrace in such situations, we would need to save
rbp, too, as your patch does. The patch might even not be enough, if there is
the possibility that we could .cfi_def_cfa_register with a register other than
rbp/6. In that case, the patch can be ignored and it is left to disable the
optimization by default, as you already suggested, I think you already have a
patch for that.
H.J. Lu's patch to emit .cfi_undefined is needed in any case. Only that both
patches are currently incompatible.
There also seems to be a bug in libgcc/unwind-dw2.c:249, causing a SEGV when
register values are unavailable due to .cfi_undefined. This is already known,
as the comment there suggests. This happens during a call to glibc's
backtrace(), even though the registers are not needed for the backtrace (in
that case, gdb's backtrace is fine, glibc's backtrace crashes in libgcc). It
should be possible to print best-effort-traces without crashing, in fact,
calling backtrace() should never lead to a crash. Bug 103510 might be related
and this should be fixed independently.
Thanks for the work putting in this and I am sorry for the mess on my side!
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534#c45
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (15 preceding siblings ...)
2024-03-01 6:44 ` lukas.graetz@tu-darmstadt.de
@ 2024-03-05 9:26 ` cvs-commit at gcc dot gnu.org
2024-03-05 9:43 ` jakub at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-05 9:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
--- Comment #15 from GCC 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:8ee6d13e32279faf9ef4fd8eabfba0adfca0dfb9
commit r14-9313-g8ee6d13e32279faf9ef4fd8eabfba0adfca0dfb9
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Mar 5 10:24:51 2024 +0100
i386: For noreturn functions save at least the bp register if it is used
[PR114116]
As mentioned in the PR, on x86_64 currently a lot of ICEs end up
with crashes in the unwinder like:
during RTL pass: expand
pr114044-2.c: In function âfooâ:
pr114044-2.c:5:3: internal compiler error: in expand_fn_using_insn, at
internal-fn.cc:208
5 | __builtin_clzg (a);
| ^~~~~~~~~~~~~~~~~~
0x7d9246 expand_fn_using_insn
../../gcc/internal-fn.cc:208
pr114044-2.c:5:3: internal compiler error: Segmentation fault
0x1554262 crash_signal
../../gcc/toplev.cc:319
0x2b20320 x86_64_fallback_frame_state
./md-unwind-support.h:63
0x2b20320 uw_frame_state_for
../../../libgcc/unwind-dw2.c:1013
0x2b2165d _Unwind_Backtrace
../../../libgcc/unwind.inc:303
0x2acbd69 backtrace_full
../../libbacktrace/backtrace.c:127
0x2a32fa6 diagnostic_context::action_after_output(diagnostic_t)
../../gcc/diagnostic.cc:781
0x2a331bb diagnostic_action_after_output(diagnostic_context*, diagnostic_t)
../../gcc/diagnostic.h:1002
0x2a331bb diagnostic_context::report_diagnostic(diagnostic_info*)
../../gcc/diagnostic.cc:1633
0x2a33543 diagnostic_impl
../../gcc/diagnostic.cc:1767
0x2a33c26 internal_error(char const*, ...)
../../gcc/diagnostic.cc:2225
0xe232c8 fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:2336
0x7d9246 expand_fn_using_insn
../../gcc/internal-fn.cc:208
Segmentation fault (core dumped)
The problem are the PR38534 r14-8470 changes which avoid saving call-saved
registers in noreturn functions. If such functions ever touch the
bp register but because of the r14-8470 changes don't save it in the
prologue, the caller or any other function in the backtrace uses a frame
pointer and the noreturn function or anything it calls directly or
indirectly calls backtrace, then the unwinder crashes, because bp register
contains some unrelated value, but in the frames which do use frame pointer
CFA is based on the bp register.
In theory this could happen with any other call-saved register, e.g. code
written by hand in assembly with .cfi_* directives could use any other
call-saved register as register into which store the CFA or something
related to that, but in reality at least compiler generated code and usual
assembly probably just making sure bp doesn't contain garbage could be
enough for backtrace purposes. In the debugger of course it will not be
enough, the values of the arguments etc. can be lost (if DW_CFA_undefined
is emitted) or garbage.
So, I think for noreturn function we should at least save the bp register
if we use it. If user asks for it using no_callee_saved_registers
attribute, let's honor what is asked for (but then it is up to the user
to make sure e.g. backtrace isn't called from the function or anything it
calls). As discussed in the PR, whether to save bp or not shouldn't be
based on whether compiling with -g or -g0, because we don't want code
generation changes without/with debugging, it would also break
-fcompare-debug, and users can call backtrace(3), that doesn't use debug
info, just unwind info, even backtrace_symbols{,_fd}(3) don't use debug
info
but just looks at dynamic symbol table.
The patch also adds check for no_caller_saved_registers
attribute in the implicit addition of not saving callee saved register
in noreturn functions, because on I think
__attribute__((no_caller_saved_registers, noreturn)) will otherwise
error that no_caller_saved_registers and no_callee_saved_registers
attributes are incompatible (but user didn't specify anything like that).
2024-03-05 Jakub Jelinek <jakub@redhat.com>
PR target/114116
* config/i386/i386.h (enum call_saved_registers_type): Add
TYPE_NO_CALLEE_SAVED_REGISTERS_EXCEPT_BP enumerator.
* config/i386/i386-options.cc (ix86_set_func_type): Remove
has_no_callee_saved_registers variable, add
no_callee_saved_registers
instead, initialize it depending on whether it is
no_callee_saved_registers function or not. Don't set it if
no_caller_saved_registers attribute is present. Adjust users.
* config/i386/i386.cc (ix86_function_ok_for_sibcall): Handle
TYPE_NO_CALLEE_SAVED_REGISTERS_EXCEPT_BP like
TYPE_NO_CALLEE_SAVED_REGISTERS.
(ix86_save_reg): Handle TYPE_NO_CALLEE_SAVED_REGISTERS_EXCEPT_BP.
* gcc.target/i386/pr38534-1.c: Allow push/pop of bp.
* gcc.target/i386/pr38534-4.c: Likewise.
* gcc.target/i386/pr38534-2.c: Likewise.
* gcc.target/i386/pr38534-3.c: Likewise.
* gcc.target/i386/pr114097-1.c: Likewise.
* gcc.target/i386/stack-check-17.c: Expect no pop on ! ia32.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc
2024-02-26 14:56 [Bug target/114116] New: [14 Regression] Broken backtraces in bootstrapped x86_64 gcc jakub at gcc dot gnu.org
` (16 preceding siblings ...)
2024-03-05 9:26 ` cvs-commit at gcc dot gnu.org
@ 2024-03-05 9:43 ` jakub at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-03-05 9:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 19+ messages in thread