[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[js at alien8 dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534

Julian Stecklina <js at alien8 dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |js at alien8 dot de

--- Comment #3 from Julian Stecklina <js at alien8 dot de> 2011-11-07 00:14:46 UTC ---
This still applies to GCC 4.6.2.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
most of C++ exception tests crashed.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=10837

--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to thutt from comment #2)
PR10837 has some discussion on this point too.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

Lukas Grätz <lukas.graetz@tu-darmstadt.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lukas.graetz@tu-darmstadt.d
                   |                            |e

--- Comment #6 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Sam James from comment #5)
> (In reply to thutt from comment #2)
> PR10837 has some discussion on this point too.

The debugging argument there was for the backtrace. For that we only need to
follow the calling conventions to save the stack and instruction pointers.
Other registers, including callee saved registers like r12,r13,r14,r15 are not
used in a backtrace.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #7 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to H.J. Lu from comment #4)
> When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> most of C++ exception tests crashed.

Can you tell how you compiled it? Thanks in advance!

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-14
             Status|UNCONFIRMED                 |NEW

--- 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 #4)
> > When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> > libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> > most of C++ exception tests crashed.
> 
> Can you tell how you compiled it? Thanks in advance!

I have a patch to fix it. Please try users/hjl/pr113312/gcc-13 branch:

https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13?ref_type=heads

For your testcase, I got

        .globl  no_return_to_caller
        .type   no_return_to_caller, @function
no_return_to_caller:
.LFB0:
        .cfi_startproc
        subq    $24, %rsp
        .cfi_def_cfa_offset 32
        movl    $array+67108860, %eax
        xorl    %r13d, %r13d
        movq    %rax, 8(%rsp)
.L2:
        movl    $256, %ebp
        movq    8(%rsp), %r12
        movl    $256, %ebx
        subl    %r13d, %ebp
        .p2align 4,,10
        .p2align 3
.L6:
        movq    %r12, %r14
        movl    $256, %r15d
        .p2align 4,,10
        .p2align 3
.L3:
        movl    %r15d, %edx
        movl    %ebx, %esi
        movl    %ebp, %edi
        subl    $1, %r15d
        call    value
        subq    $4, %r14
        movl    %eax, 4(%r14)
        testl   %r15d, %r15d
        jne     .L3
        subq    $1024, %r12
        subl    $1, %ebx
        jne     .L6
        subq    $262144, 8(%rsp)
        addq    $1, %r13
        cmpq    $256, %r13
        jne     .L2
.L5:
        jmp     .L5
        .cfi_endproc
.LFE0:
        .size   no_return_to_caller, .-no_return_to_caller

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- 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 #4)
> > > When I compiled __cxxabiv1::__cxa_throw, which is a noreturn function in
> > > libstdc++-v3/libsupc++/eh_throw.cc not to save callee-saved registers,
> > > most of C++ exception tests crashed.
> > 
> > Can you tell how you compiled it? Thanks in advance!
> 
> I have a patch to fix it. Please try users/hjl/pr113312/gcc-13 branch:
> 
> 
> For your testcase, I got

Well it is not my testcase. But I added backtracing and observed that the
printed backtrace is unchanged with your patch. The new no_return_to_caller():

void __attribute__((noreturn))
no_return_to_caller(int a, int b, int c, int d)
{
   LOOP_BODY;

#define BT_BUF_SIZE 100
   void *buffer[BT_BUF_SIZE];
   backtrace_symbols_fd(buffer, backtrace(buffer, BT_BUF_SIZE), STDOUT_FILENO);

   while (1);
}

What I observed from the assembly is that %rbp is not saved, whereas %rip and
%rsp are still implicitly saved by the call instruction. But since glibc's
backtrace implementation does not use %rbp, this is fine.

Some amateur speculation, just ignore it: I don't know whether %rbp is the
source of the failed C++ test cases, which also do some stack unwinding. After
looking in the System V Abi specification I am still unsure whether stack
unwinding relies on %rbp or not. Perhaps there is an unnecessary dependency on
%rbp or a missing "-fno-omit-frame-pointer" somewhere in the gcc internals that
causes the problem.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Lukas Grätz from comment #9)

> Well it is not my testcase. But I added backtracing and observed that the
> printed backtrace is unchanged with your patch. The new
> no_return_to_caller():
> 
> void __attribute__((noreturn))
> no_return_to_caller(int a, int b, int c, int d)
> {
>    LOOP_BODY;
> 
> #define BT_BUF_SIZE 100
>    void *buffer[BT_BUF_SIZE];
>    backtrace_symbols_fd(buffer, backtrace(buffer, BT_BUF_SIZE),
> STDOUT_FILENO);
> 
>    while (1);
> }
> 
> What I observed from the assembly is that %rbp is not saved, whereas %rip
> and %rsp are still implicitly saved by the call instruction. But since
> glibc's backtrace implementation does not use %rbp, this is fine.
> 
> Some amateur speculation, just ignore it: I don't know whether %rbp is the
> source of the failed C++ test cases, which also do some stack unwinding.
> After looking in the System V Abi specification I am still unsure whether
> stack unwinding relies on %rbp or not. Perhaps there is an unnecessary
> dependency on %rbp or a missing "-fno-omit-frame-pointer" somewhere in the
> gcc internals that causes the problem.

The C++ test issue is caused by missing callee-saved registers for
exception supports in noreturn functions in libstdc++.  I fixed it by
keeping callee-saved registers when exception is enabled.

Backtrace with %rbp is unrelated to this.  Gcc will skip %rpb without
-fno-omit-frame-pointer.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #11 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++.  I fixed it by
> keeping callee-saved registers when exception is enabled.
> 
> Backtrace with %rbp is unrelated to this.  Gcc will skip %rpb without
> -fno-omit-frame-pointer.

Great! Then I guess there is no pitfall in your patch.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #12 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to H.J. Lu from comment #10)
> The C++ test issue is caused by missing callee-saved registers for
> exception supports in noreturn functions in libstdc++.  I fixed it by
> keeping callee-saved registers when exception is enabled.


I guess that exception throwing needs callee-saved registers, because it uses
stack unwinding to do something very similar to a return.


void f1(void) {
  CODE, compiler translation uses callee-saved %r12
  f2();
  CODE, compiler translation uses callee-saved %r12
}

void f2(void) {
  f3();
}

void f3(void) {
  CODE, compiler translation uses callee-saved %r12
  f4();
  while(1);
}

void f4(void) {
  CODE, uses loop unwinding functions
        a) restores all callee-saved registers in f3(), f2()
        b) restores %rsp and %rip from stack of f2()
  unreachable();
}

In effect, b) is a return from the call f2() in f1(), although it happens in
f4().

%r12 needs only to be saved in f1() and f3(). Gcc with -O2 would do that.
However, with your patch, %r12 would not be saved in f3() anymore. This can
lead to crashing in the second CODE block in f1().

The solution should require __attribute__((nothrow)) in addition to noreturn in
your optimization patch. The b) in f4() should/would be treated as a throw. So
none of f1(), f2(), f3() should have the attribute nothrow.

So in the example of this report, the signature of value() should be modified
to:

extern __attribute__((nothrow)) unsigned value(int i, int j, int k);

Only then it is safe to skip saving callee-saved registers. "nothrow" should
also be added to bar() and fn() in your test case pr38534-2.c.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #13 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Lukas Grätz from comment #12)

>   CODE, uses loop unwinding functions
>        a) restores all callee-saved registers in f3(), f2()
>        b) restores %rsp and %rip from stack of f2()

I meant stack unwinding.  f3() and f2() can be in separate compilation units,
it needs is ".cfi_offset REGISTER, OFFSET" from the elf (also in the generated
assembly).

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #14 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
Never mind my above comments. I just realized that attribute nothrow has no
effect in C, unless -fexceptions. So nothrow is not needed (only
-fno-exceptions). Furthermore, most noreturn functions throw in C++, so there
would be little potential optimization when exceptions are enabled.

What puzzles me, is that functions like exit() have different signatures in C
and C++. With "gcc -E -fexceptions somefile.cc" I get

  extern void exit (int __status)
    throw () __attribute__ ((__noreturn__));

in C++ and in C I get with "gcc -E -fexceptions somefile.c"

  extern void exit (int __status)
    __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__noreturn__));

, although exceptions are explicitly enabled in both cases. But I guess this is
a problem in Glibc, not GCC.

I will really shut up now, promise!

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:7cc9adc62cee0aa91ce834b3dd6296ce38f1d79d

commit r14-8470-g7cc9adc62cee0aa91ce834b3dd6296ce38f1d79d
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Jan 23 06:59:51 2024 -0800

    x86: Don't save callee-saved registers in noreturn functions

    There is no need to save callee-saved registers in noreturn functions
    if they don't throw nor support exceptions.  We can treat them the same
    as functions with no_callee_saved_registers attribute.

    Adjust stack-check-17.c for noreturn function which no longer saves any
    registers.

    With this change, __libc_start_main in glibc 2.39, which is a noreturn
    function, is changed from

    __libc_start_main:
            endbr64
            push   %r15
            push   %r14
            mov    %rcx,%r14
            push   %r13
            push   %r12
            push   %rbp
            mov    %esi,%ebp
            push   %rbx
            mov    %rdx,%rbx
            sub    $0x28,%rsp
            mov    %rdi,(%rsp)
            mov    %fs:0x28,%rax
            mov    %rax,0x18(%rsp)
            xor    %eax,%eax
            test   %r9,%r9

    to

    __libc_start_main:
            endbr64
            sub    $0x28,%rsp
            mov    %esi,%ebp
            mov    %rdx,%rbx
            mov    %rcx,%r14
            mov    %rdi,(%rsp)
            mov    %fs:0x28,%rax
            mov    %rax,0x18(%rsp)
            xor    %eax,%eax
            test   %r9,%r9

    In Linux kernel 6.7.0 on x86-64, do_exit is changed from

    do_exit:
            endbr64
            call   <do_exit+0x9>
            push   %r15
            push   %r14
            push   %r13
            push   %r12
            mov    %rdi,%r12
            push   %rbp
            push   %rbx
            mov    %gs:0x0,%rbx
            sub    $0x28,%rsp
            mov    %gs:0x28,%rax
            mov    %rax,0x20(%rsp)
            xor    %eax,%eax
            call   *0x0(%rip)        # <do_exit+0x39>
            test   $0x2,%ah
            je     <do_exit+0x8d3>

    to

    do_exit:
            endbr64
            call   <do_exit+0x9>
            sub    $0x28,%rsp
            mov    %rdi,%r12
            mov    %gs:0x28,%rax
            mov    %rax,0x20(%rsp)
            xor    %eax,%eax
            mov    %gs:0x0,%rbx
            call   *0x0(%rip)        # <do_exit+0x2f>
            test   $0x2,%ah
            je     <do_exit+0x8c9>

    I compared GCC master branch bootstrap and test times on a slow machine
    with 6.6 Linux kernels compiled with the original GCC 13 and the GCC 13
    with the backported patch.  The performance data isn't precise since the
    measurements were done on different days with different GCC sources under
    different 6.6 kernel versions.

    GCC master branch build time in seconds:

    before                after                  improvement
    30043.75user          30013.16user           0%
    1274.85system         1243.72system          2.4%

    GCC master branch test time in seconds (new tests added):

    before                after                  improvement
    216035.90user         216547.51user          0
    27365.51system        26658.54system         2.6%

    gcc/

            PR target/38534
            * config/i386/i386-options.cc (ix86_set_func_type): Don't
            save and restore callee saved registers for a noreturn function
            with nothrow or compiled with -fno-exceptions.

    gcc/testsuite/

            PR target/38534
            * gcc.target/i386/pr38534-1.c: New file.
            * gcc.target/i386/pr38534-2.c: Likewise.
            * gcc.target/i386/pr38534-3.c: Likewise.
            * gcc.target/i386/pr38534-4.c: Likewise.
            * gcc.target/i386/stack-check-17.c: Updated.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Won't this screw up backtrace calls in such functions, or
__builtin_frame_address calls, or backtraces in debugger and other tools?

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we somehow
indicate in DWARF unwind info that the callee saved registers weren't saved and
were clobbered?  Even if backtrace itself still works make it clear that if
debugger unwinds to caller frame that certain registers have unknown values
rather than the restored ones.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #17)
> E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we

We can disable this for -O0 and -Og.

> somehow indicate in DWARF unwind info that the callee saved registers
> weren't saved and were clobbered?  Even if backtrace itself still works make

Is there such a DWARF bit?

> it clear that if debugger unwinds to caller frame that certain registers
> have unknown values rather than the restored ones.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #18)
> (In reply to Jakub Jelinek from comment #17)
> > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
> 
> We can disable this for -O0 and -Og.

I think we should go for that.

> > somehow indicate in DWARF unwind info that the callee saved registers
> > weren't saved and were clobbered?  Even if backtrace itself still works make
> 
> Is there such a DWARF bit?

There is the undefined state (DW_CFA_undefined, .cfi_undefined directive in
gas).
But DWARF says undefined is the default state unless an ABI specifies something
else for certain registers (or unless overridden in CIE or FDE), so I must say
I don't remember what is done usually and whether the default state isn't what
is enough.
But it would really surprise me if the call saved registers weren't treated as
same_value at the start of the function and I believe nothing emits
DW_CFA_same_value in the CIEs.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aburgess at redhat dot com,
                   |                            |blarsen at redhat dot com,
                   |                            |kevinb at redhat dot com,
                   |                            |tromey at gcc dot gnu.org

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess we should CC some GDB people on this.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[aburgess at redhat dot com]

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

--- Comment #21 from Andrew Burgess <aburgess at redhat dot com> ---
Setting to DW_CFA_undefined is the right thing to do.  DWARF says:

  The DW_CFA_undefined instruction takes a single unsigned LEB128 operand
  that represents a register number. The required action is to set the rule for
the
  specified register to “undefined.”

which is exactly what you'd want here.

GDB has a distinction between "unspecified" (not really a DWARF thing) and
"undefined" (the DWARF thing).  Registers that aren't given an initial state in
the CIE start as "unspecified", the idea being (I believe) that we then apply
some kind of ABI based rules on top.  So an "unspecified" call-clobbered
register would be treated as "undefined", while a callee-saved register would
be treated as "same-value" to begin with.

Setting a register to "undefined" in the DWARF should, I think, do what you
want.

At least, if it doesn't, I think that would be on GDB to fix.

This is just my personal thoughts, others might disagree.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[hjl.tools at gmail dot com]

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

--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 57243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57243&action=edit
A patch to generate .cfi_undefined for unsaved callee-saved registers

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[hjl.tools at gmail dot com]

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

--- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Andrew Burgess from comment #21)
> Setting to DW_CFA_undefined is the right thing to do.  DWARF says:
> 
>   The DW_CFA_undefined instruction takes a single unsigned LEB128 operand
>   that represents a register number. The required action is to set the rule
> for the
>   specified register to “undefined.”
> 
> which is exactly what you'd want here.
> 
> GDB has a distinction between "unspecified" (not really a DWARF thing) and
> "undefined" (the DWARF thing).  Registers that aren't given an initial state
> in the CIE start as "unspecified", the idea being (I believe) that we then
> apply some kind of ABI based rules on top.  So an "unspecified"
> call-clobbered register would be treated as "undefined", while a
> callee-saved register would be treated as "same-value" to begin with.
> 
> Setting a register to "undefined" in the DWARF should, I think, do what you
> want.

A patch is posted at

https://patchwork.sourceware.org/project/gcc/list/?series=30283

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:291f75fa1bc6a23c6184bb99c726074b13f2f18e

commit r14-8495-g291f75fa1bc6a23c6184bb99c726074b13f2f18e
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sat Jan 27 05:48:45 2024 -0800

    x86: Save callee-saved registers in noreturn functions for -O0/-Og

    Save callee-saved registers in noreturn functions for -O0/-Og so that
    debugger can restore callee-saved registers in caller's frame.

    Also add the TREE_THIS_VOLATILE check to minimize noreturn attribute
    lookup.

    gcc/

            PR target/38534
            * config/i386/i386-options.cc (ix86_set_func_type): Save
            callee-saved registers in noreturn functions for -O0/-Og.

    gcc/testsuite/

            PR target/38534
            * gcc.target/i386/pr38534-5.c: New file.
            * gcc.target/i386/pr38534-6.c: Likewise.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #25 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Jakub Jelinek from comment #17)
> > > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
> > 
> > We can disable this for -O0 and -Og.
> 
> I think we should go for that.
> 

This is independent from debugging, but I thought the patch was only meant for
-O3. Have you thought about the following situation:


Compile with gcc -O1 (and --fno-exception is implicit):
---- library.c ----------------
void __attribute__((noreturn))
foo(void (*bar)(void)) {
    ...
    bar();
    while (1);
}
---------------------


Compile with g++ (and -fexception is implicit):
---- app.c++ ----------------
#include <iostream>

extern void foo(void (*bar)(void));
extern void bar_throws_exception(void) throw ();

int main() {
    ...
    try
    {
        foo(bar_throws_exception);
    }
    catch (const std::exception& e)
    {
        ...
    }
}
----------------------


It is not hart to fill the ... to make it use some callee-saved registers (e.g.
with LOOP_BODY as in this issue report). And then the program would crash.

One might argue that either the library.c is to blame for the missing
-fexceptions? Or that the app.c++ is to blame because it should not call foo
with an argument function that might throw an exception? I am unsure if the C++
standard actually forbids calling C library functions with argument functions
that might throw an exception.

So I think it would be safer to restrict the patch to -O3. But I really don't
know much about this.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Lukas Grätz from comment #25)
> (In reply to Jakub Jelinek from comment #19)
> > (In reply to H.J. Lu from comment #18)
> > > (In reply to Jakub Jelinek from comment #17)
> > > > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
> > > 
> > > We can disable this for -O0 and -Og.
> > 
> > I think we should go for that.
> > 
> 
> This is independent from debugging, but I thought the patch was only meant
> for -O3. Have you thought about the following situation:

Throwing an exception through -fno-exceptions code is UB, don't do that.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #27 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Lukas Grätz from comment #25)
> > (In reply to Jakub Jelinek from comment #19)
> > > (In reply to H.J. Lu from comment #18)
> > > > (In reply to Jakub Jelinek from comment #17)
> > > > > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
> > > > 
> > > > We can disable this for -O0 and -Og.
> > > 
> > > I think we should go for that.
> > > 
> > 
> > This is independent from debugging, but I thought the patch was only meant
> > for -O3. Have you thought about the following situation:
> 
> Throwing an exception through -fno-exceptions code is UB, don't do that.

Thanks for the info!

I guess this UB is implicit in GCC's documentation for "-fexceptions":

"However, you may need to enable this option when compiling C code that needs
to interoperate properly with exception handlers written in C++."

I would suggest to remove the "may" and to be more clear:

"However, you need to enable this option when compiling C code that could
(implicitly) propagate an exception (from C++) to an exception handler written
in C++."

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Lukas Grätz from comment #9)
> Well it is not my testcase. But I added backtracing and observed that the
> printed backtrace is unchanged with your patch. The new
> no_return_to_caller():

You haven't tried hard enough.
Consider the testcase I've posted to the mailing list, built with -Og -g.
It is artificial in that register pressure is increased artificially rather
than coming from meaningful code, noipa attribute is used heavily instead of
functions being too large or in different TUs, and optimize attribute used
instead of the noreturn function sitting in a different library, built there
with -O2, while user program say with -Og.

extern void abort (void);
volatile unsigned v = 0xdeadbeefU;
int w;

__attribute__((noipa)) void
corge (char *p)
{
  (void) p;
}

__attribute__((noipa)) int
foo (int x)
{
  return x;
}

__attribute__((noipa, noreturn, optimize (2))) void
bar (void)
{
  unsigned a = v;
  unsigned b = v;
  unsigned c = v;
  unsigned d = v;
  unsigned e = v;
  unsigned f = v;
  unsigned g = v;
  unsigned h = v;
  int i = foo (50);
  v = a + b + c + d + e + f + g + h;
  abort ();
}

__attribute__((noipa)) void
baz (int a, int b, int c, int d, int e, int f, int g, int h)
{
  int i = foo (51);
  if (w)
    bar ();
}

__attribute__((noipa)) void
qux (void)
{
  int a = foo (42);
  int b = foo (43);
  int c = foo (44);
  int d = foo (45);
  int e = foo (46);
  int f = foo (47);
  int g = foo (48);
  int h = foo (49);
  corge (__builtin_alloca (foo (52)));
  baz (a, b, c, d, e, f, g, h);
  w++;
  baz (a, b, c, d, e, f, g, h);
  baz (a, b, c, d, e, f, g, h);
}

int
main ()
{
  qux ();
}

Before the r14-8470 changes the backtrace on abort was

#0  0x00007ffff7dbd765 in abort () from /lib64/libc.so.6                        
#1  0x00000000004011ca in bar () at /tmp/1.c:30                                 
#2  0x00000000004011f1 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
d=d@entry=45, e=e@entry=46, f=f@entry=47, g=48, h=49) at /tmp/1.c:38            
#3  0x00000000004012d8 in qux () at /tmp/1.c:55                                 
#4  0x0000000000401319 in main () at /tmp/1.c:62                                

The gcc trunk hits the backtrace not possible problem because rbp is            
clobbered and needed in upper frame CFA computation:                            

#0  0x00007ffff7dbd765 in abort () from /lib64/libc.so.6                        
#1  0x00000000004011b0 in bar () at /tmp/1.c:30                                 
#2  0x00000000004011d1 in baz (a=<error reading variable: Cannot access memory
at address 0xdeadbebb>, b=<error reading variable: Cannot access memory at
address 0xdeadbeb7>,        
    c=<error reading variable: Cannot access memory at address 0xdeadbeb3>,
d=d@entry=-559038737, e=e@entry=-559038737, f=f@entry=-559038737, g=48, h=49)
at /tmp/1.c:38              
#3  0x00000000004012a9 in qux () at /tmp/1.c:55                                 
Backtrace stopped: previous frame inner to this frame (corrupt stack?)          

And in the patched gcc (with PR114116 patch to save bp register) backtrace
works but several of the values are bogus:                                      
#0  0x00007ffff7dbd765 in abort () from /lib64/libc.so.6                        
#1  0x00000000004011b1 in bar () at /tmp/1.c:30                                 
#2  0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
d=d@entry=-559038737, e=e@entry=-559038737, f=f@entry=-559038737, g=48, h=49)
at /tmp/1.c:38                 
#3  0x00000000004012aa in qux () at /tmp/1.c:55                                 
#4  0x00000000004012e4 in main () at /tmp/1.c:62                                

So, I think we should limit this to -fno-unwind-tables or maybe
-mcmodel=kernel.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #29 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Lukas Grätz from comment #9)
> > Well it is not my testcase. But I added backtracing and observed that the
> > printed backtrace is unchanged with your patch. The new
> > no_return_to_caller():
> 
> You haven't tried hard enough.


That might be true.


> Consider the testcase I've posted to the mailing list, built with -Og -g.

> The gcc trunk hits the backtrace not possible problem because rbp is        
> 
> clobbered and needed in upper frame CFA computation:                        


Yes, when a backtrace is based on rbp, one needs -fno-omit-frame-pointer. I
trusted comment #10 here, as it made sense.


> And in the patched gcc (with PR114116 patch to save bp register) backtrace
> works but several of the values are bogus:                                  

> #2  0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> d=d@entry=-559038737, e=e@entry=-559038737, f=f@entry=-559038737, g=48,
> h=49) at /tmp/1.c:38


glibc's backtrace() function and friends only reports function names and
addresses. This looks like the gdb bt command. I admit, I did not take a proper
look into that before.

I belief this could and should be somehow be fixed by adding DWARF info that
certain callee-saved registers (= the function parameter values) were
overwritten. The corrected backtrace could look something like this:


#2  0x00000000004011d2 in baz (a=42, b=43, c=44, d=<optimised out>,
e=<optimised out>, f=<optimised out>, g=48, h=49) at /tmp/1.c:38


Some parameters would be <optimised out>, and this would be fine because the
code was partially compiled with -O2. It is not unusual to have <optimised out>
parameter values in gdb's bt.


> So, I think we should limit this to -fno-unwind-tables or maybe
> -mcmodel=kernel.


Now I am confused. The optimization is limited to -fexceptions. And the
documentation of -funwind-tables says "Similar to -fexceptions, except". So
shouldn't -funwind-tables behave similar to -fexceptions? I don't see anything
kernel-specific here.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Lukas Grätz from comment #29)
> Yes, when a backtrace is based on rbp, one needs -fno-omit-frame-pointer. I
> trusted comment #10 here, as it made sense.

See PR114116.

> glibc's backtrace() function and friends only reports function names and
> addresses. This looks like the gdb bt command. I admit, I did not take a
> proper look into that before.

Yes, it is gdb bt.  And it is what people heavily rely on for debugging, if
something fails an assertion or aborts etc., they want to figure out why.

> I belief this could and should be somehow be fixed by adding DWARF info that
> certain callee-saved registers (= the function parameter values) were
> overwritten. The corrected backtrace could look something like this:

That can be arranged by emitting those .cfi_undefined directives...

> #2  0x00000000004011d2 in baz (a=42, b=43, c=44, d=<optimised out>,
> e=<optimised out>, f=<optimised out>, g=48, h=49) at /tmp/1.c:38

... but really will not help users to debug/fix their code.

> > So, I think we should limit this to -fno-unwind-tables or maybe
> > -mcmodel=kernel.
> Now I am confused. The optimization is limited to -fexceptions. And the
> documentation of -funwind-tables says "Similar to -fexceptions, except". So
> shouldn't -funwind-tables behave similar to -fexceptions? I don't see
> anything kernel-specific here.

Given that even with -fno-asynchronous-unwind-tables (or -fno-unwind-tables)
gcc emits
the unwind info, just not into .eh_frame but .debug_frame, we shouldn't disable
it
just when not emitting .eh_frame, but should just disable it always.
There is a reason why it has been rejected years ago.
If anything, guard it with some non-default -m* option and explain the
consequences to users if they use it.  Still, the guarding IMHO should be done
on top of the PR114116
change, because having random crashes from backtrace or gdb bt even when user
asked for it is a bad idea.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #31 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Lukas Grätz from comment #29)
> > Yes, when a backtrace is based on rbp, one needs -fno-omit-frame-pointer. I
> > trusted comment #10 here, as it made sense.
> 
> See PR114116.
> 
> > glibc's backtrace() function and friends only reports function names and
> > addresses. This looks like the gdb bt command. I admit, I did not take a
> > proper look into that before.
> 
> Yes, it is gdb bt.  And it is what people heavily rely on for debugging, if
> something fails an assertion or aborts etc., they want to figure out why.
> 

True.

> > I belief this could and should be somehow be fixed by adding DWARF info that
> > certain callee-saved registers (= the function parameter values) were
> > overwritten. The corrected backtrace could look something like this:
> 
> That can be arranged by emitting those .cfi_undefined directives...
>  
> > #2  0x00000000004011d2 in baz (a=42, b=43, c=44, d=<optimised out>,
> > e=<optimised out>, f=<optimised out>, g=48, h=49) at /tmp/1.c:38
> 
> ... but really will not help users to debug/fix their code.


Even when I compile a simple program with gcc -O2 -g:


#include <stdlib.h>
int main(int argc, char** argv) {
    abort();
}


I still get an "argc=<optimised out>":

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7dcd859 in __GI_abort () at abort.c:79
#2  0x0000000000401046 in main (argc=<optimised out>, argv=<optimised out>) at
simple.c:4


Yes, for a better debugging, it would be nice if optimised code would just not
be optimised... But this goes against optimization.


> > > So, I think we should limit this to -fno-unwind-tables or maybe
> > > -mcmodel=kernel.
> > Now I am confused. The optimization is limited to -fexceptions. And the
> > documentation of -funwind-tables says "Similar to -fexceptions, except". So
> > shouldn't -funwind-tables behave similar to -fexceptions? I don't see
> > anything kernel-specific here.
> 
> Given that even with -fno-asynchronous-unwind-tables (or -fno-unwind-tables)
> gcc emits
> the unwind info, just not into .eh_frame but .debug_frame, we shouldn't
> disable it
> just when not emitting .eh_frame, but should just disable it always.
> There is a reason why it has been rejected years ago.
> If anything, guard it with some non-default -m* option and explain the
> consequences to users if they use it.  Still, the guarding IMHO should be
> done on top of the PR114116
> change, because having random crashes from backtrace or gdb bt even when
> user asked for it is a bad idea.


Yes, it is a bad idea to have crashes from backtrace or gdb. But when this is
only about <optimised out>, I don't see the point about disabling it always.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Lukas Grätz from comment #31)
> Even when I compile a simple program with gcc -O2 -g:
> 
> #include <stdlib.h>
> int main(int argc, char** argv) {
>     abort();
> }
> 
> 
> I still get an "argc=<optimised out>":

Sure, debugging info in optimized code is best effort.

> Yes, for a better debugging, it would be nice if optimised code would just
> not be optimised... But this goes against optimization.

The significant difference between other optimizations and this one is
that normal optimizations affect the debuggability of the optimized function.
This one affects the debuggability of all callers as well, even if they are
compiled in a way that should make them more debuggable.
Normally, if debugging optimized code doesn't work out, one can simply
rebuild that code with -O0 or -Og to make it more debuggable.
Here one would also need to rebuild all the shared libraries it uses.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #33 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #32)
> (In reply to Lukas Grätz from comment #31)
> > Even when I compile a simple program with gcc -O2 -g:
> > 
> > #include <stdlib.h>
> > int main(int argc, char** argv) {
> >     abort();
> > }
> > 
> > 
> > I still get an "argc=<optimised out>":
> 
> Sure, debugging info in optimized code is best effort.
> 
> > Yes, for a better debugging, it would be nice if optimised code would just
> > not be optimised... But this goes against optimization.
> 
> The significant difference between other optimizations and this one is
> that normal optimizations affect the debuggability of the optimized function.
> This one affects the debuggability of all callers as well, even if they are
> compiled in a way that should make them more debuggable.
> Normally, if debugging optimized code doesn't work out, one can simply
> rebuild that code with -O0 or -Og to make it more debuggable.
> Here one would also need to rebuild all the shared libraries it uses.

When the debugger is inside the debuggable -O0 or -Og compiled function, we
would see all parameters and current variable values. However, in the bt
example, we are in another function. So the parameters are only available at
best effort.

I just noticed that for my simple.c example above, I get "argc=<optimised out>"
even with -Og. However, when breakpoint is somewhere else,

(gdb) break main
(gdb) run
(gdb) bt

I get the correct "argc=1". The same applies to your example with "break baz".
It is just not guaranteed that gdb is able to reconstruct function parameters
when we are in some other function.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Best effort are the whatever@entry values, that is used if an argument is no
longer used across the function call and isn't stored in any call saved
register or stack slot.
There can be also automatic variables which are live across the call (note,
even if you have noreturn function lower in the call stack, its caller e.g.
could just call the noreturn function conditionally or could be from a
different translation unit in which the callee is not declared noreturn, and
any caller up in the call stack then won't have noreturn calls).
If you have
  int x = fn1 (...);
  fn2 (...); // This function conditionally calls a noreturn function
  fn3 (x);
then typically x will be in callee saved register (unless we run out of them),
it isn't best effort in there, the debug info just says that say x lives in
%ebx register,
it doesn't say it might be in that register.
Now, when you up from the noreturn function to this frame, gdb won't be able to
restore the register (if .cfi_undefined is emitted), or right now just can have
completely bogus values.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If I hand edit the gcc trunk + PR114116 patch assembly, add to bar
+       .cfi_undefined 3
+       .cfi_undefined 12
+       .cfi_undefined 13
+       .cfi_undefined 14
+       .cfi_undefined 15
then bt in gdb shows
#2  0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
d=<error reading variable: value has been optimized out>, 
    e=<error reading variable: value has been optimized out>, f=<error reading
variable: value has been optimized out>, g=48, h=49) at /tmp/1.c:38
and everything in qux live across the call is <optimized out> as well,
(gdb) p $r12
$10 = <not saved>
etc. while without that
(gdb) p a
$1 = <optimized out>
(gdb) p b
$2 = <optimized out>
(gdb) p c
$3 = <optimized out>
(gdb) p d
$4 = -559038737
(gdb) p e
$5 = -559038737
(gdb) p f
$6 = -559038737
(gdb) p g
$7 = -559038737
(gdb) p h
$8 = -559038737
(gdb) p $r12
$9 = 3735928559

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #36 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #35)
> If I hand edit the gcc trunk + PR114116 patch assembly, add to bar
> +	.cfi_undefined 3
> +	.cfi_undefined 12
> +	.cfi_undefined 13
> +	.cfi_undefined 14
> +	.cfi_undefined 15
> then bt in gdb shows
> #2  0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> d=<error reading variable: value has been optimized out>, 
>     e=<error reading variable: value has been optimized out>, f=<error
> reading variable: value has been optimized out>, g=48, h=49) at /tmp/1.c:38


I can confirm that. What bothers me, is the wording "d=<error .... optimized
out>" and not just "d=<optimized out>".


(gdb) run
Starting program: bar-artificial-mod 

Program received signal SIGABRT, Aborted.

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7dcd859 in __GI_abort () at abort.c:79
#2  0x00000000004011b1 in bar () at bar-artificial.c:30
#3  0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
d=<error reading variable: value has been optimised out>,
e=<error reading variable: value has been optimised out>,
f=<error reading variable: value has been optimised out>,
g=48, h=49) at bar-artificial.c:38
#4  0x00000000004012aa in qux () at bar-artificial.c:55
#5  0x00000000004012e4 in main () at bar-artificial.c:62

(gdb) p a
No symbol "a" in current context.
(gdb) p b
No symbol "b" in current context.


> and everything in qux live across the call is <optimized out> as well,
> (gdb) p $r12
> $10 = <not saved>
> etc. while without that
> (gdb) p a
> $1 = <optimized out>
> (gdb) p b
> $2 = <optimized out>
> (gdb) p c
> $3 = <optimized out>
> (gdb) p d
> $4 = -559038737
> (gdb) p e
> $5 = -559038737
> (gdb) p f
> $6 = -559038737
> (gdb) p g
> $7 = -559038737
> (gdb) p h
> $8 = -559038737
> (gdb) p $r12
> $9 = 3735928559


Where did you set the breakpoint? When I set it somewhere in qux (after
a,b,c,... were initialized), I get conclusive results:


(gdb) break bar-artificial.c:52
Breakpoint 1 at 0x40124a: file bar-artificial.c, line 52.
(gdb) run
Breakpoint 1, qux () at bar-artificial.c:52
52        corge (__builtin_alloca (foo (52)));
(gdb) p a
$1 = 42
(gdb) p b
$2 = 43
(gdb) p c
$3 = 44
(gdb) p d
$4 = 45
(gdb) p e 
$5 = 46
(gdb) p f
$6 = 47
(gdb) p g
$7 = 48
(gdb) p h
$8 = 49
(gdb) p $r12
$9 = 46

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Nowhere, just run and when it stops due to abort, just up several times until
reaching the appropriate frame.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #38 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #37)
> Nowhere, just run and when it stops due to abort, just up several times
> until reaching the appropriate frame.


I see, this gives me:


(gdb) frame 4
#4  0x00000000004012aa in qux () at bar-artificial.c:55
55        baz (a, b, c, d, e, f, g, h);
(gdb) p a
$1 = 42
(gdb) p b
$2 = 43
(gdb) p c
$3 = 44
(gdb) p d
$4 = <optimised out>
(gdb) p e
$5 = <optimised out>
(gdb) p f
$6 = <optimised out>
(gdb) p g
$7 = <optimised out>
(gdb) p h
$8 = <optimised out>
(gdb) p $r12
$9 = <not saved>


I checked the dwarf:


$ llvm-dwarfdump bar-artificial-mod
[...]
0x0000009f:   DW_TAG_subprogram
                DW_AT_external  (true)
                DW_AT_name      ("qux")
                DW_AT_decl_line (42)
                DW_AT_prototyped        (true)
                DW_AT_low_pc    (0x00000000004011d2)
                DW_AT_high_pc   (0x00000000004012db)
                DW_AT_frame_base        (DW_OP_call_frame_cfa)
                DW_AT_call_all_calls    (true)
                DW_AT_sibling   (cu + 0x02f0)
[...]
0x000000ee:     DW_TAG_variable
                  DW_AT_name    ("d")
                  DW_AT_decl_line       (47)
                  DW_AT_decl_column     (0x07)
                  DW_AT_type    (cu + 0x0060 "int")
[...]
$ objdump -W bar-artificial-mod
[...]
 <2><ee>: Abbrev Number: 2 (DW_TAG_variable)
    <ef>   DW_AT_name        : d
    <f1>   DW_AT_decl_file   : 1
    <f1>   DW_AT_decl_line   : 47
    <f2>   DW_AT_decl_column : 7
    <f3>   DW_AT_type        : <0x60>
    <f7>   DW_AT_location    : 0x6e (location list)
    <fb>   DW_AT_GNU_locviews: 0x6a
[...]
Contents of the .debug_loclists section:
[...]
    0000006e v000000000000000 v000000000000000 views at 0000006a for:
             0000000000401216 000000000040121f (DW_OP_reg0 (rax))
    00000075 v000000000000000 v000000000000000 views at 0000006c for:
             000000000040121f 00000000004012d1 (DW_OP_reg3 (rbx))
    0000007c <End of list>
[...]


The problem is that we are not within the loclist range. So in principle, we
cannot get the value of the variable, the variable is just not visible. But
since gdb is very clever, it searched whether either the value of rax or rbx
from within the loclist range remained somewhere. And apparently, for the
version without the patch, the value of rbx was saved. For the optimized
version with the patch, rbx was not saved, so the value could not been
reconstructed.

In my opinion, it is just fancy that gdb can do that.


Coming back to the "simple.c" example:


$ objdump -W simple
[...]
 <2><ab>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <ac>   DW_AT_name        : (indirect string, offset: 0x85): argc
    <b0>   DW_AT_decl_file   : 1
    <b0>   DW_AT_decl_line   : 2
    <b0>   DW_AT_decl_column : 14
    <b1>   DW_AT_type        : <0x35>
    <b5>   DW_AT_location    : 0x10 (location list)
    <b9>   DW_AT_GNU_locviews: 0xc
[...]
Contents of the .debug_loclists section:
[...]
    00000010 v000000000000000 v000000000000000 views at 0000000c for:
             0000000000401126 000000000040112e (DW_OP_reg5 (rdi))
    00000015 v000000000000000 v000000000000000 views at 0000000e for:
             000000000040112e 000000000040112f (DW_OP_entry_value: (DW_OP_reg5
(rdi)); DW_OP_stack_value)
    0000001d <End of list>
[...]


And rdi was saved nowhere, regardless of the patch. So gdb could not
reconstruct the value of argc.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[tromey at gcc dot gnu.org]

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

--- Comment #39 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Lukas Grätz from comment #36)

> > #2  0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > d=<error reading variable: value has been optimized out>, 
> >     e=<error reading variable: value has been optimized out>, f=<error
> > reading variable: value has been optimized out>, g=48, h=49) at /tmp/1.c:38
> 
> 
> I can confirm that. What bothers me, is the wording "d=<error .... optimized
> out>" and not just "d=<optimized out>".

Could you file a gdb bug about this?  Preferably with some
kind of test case?

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #40 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Lukas Grätz from comment #29)
> > I belief this could and should be somehow be fixed by adding DWARF info that
> > certain callee-saved registers (= the function parameter values) were
> > overwritten. The corrected backtrace could look something like this:
> 
> That can be arranged by emitting those .cfi_undefined directives...
>  
> > #2  0x00000000004011d2 in baz (a=42, b=43, c=44, d=<optimised out>,
> > e=<optimised out>, f=<optimised out>, g=48, h=49) at /tmp/1.c:38
> 
> ... but really will not help users to debug/fix their code.
> 

It seems that the reason for <optimized out> is ultimately -Og, not this patch.
See Bug 78685. When compiling and debugging your program with -O0 instead,
there is not a single <optimized out>.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[jakub at gcc dot gnu.org]

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

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Lukas Grätz from comment #40)
> It seems that the reason for <optimized out> is ultimately -Og, not this
> patch. See Bug 78685.

No.  When PR78685 would be fixed by adding artificial hidden uses of variables
at the end of their scopes, this bug would trigger far more often.  The vars
would be live across the calls, so if there would be callee-saved registers
available, the compiler
would use them to hold the variables across the calls.  And this bug would
break that.
Anyway, I've posted 
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646649.html
patch which will not revert the #c15/#c24 changes, but guard them with a
non-default option.  People who don't care about the harder debugging can use
that option in their code, but widely used shared libraries with noreturn
entrypoints will no longer screw up the debugging for all the packages that use
them.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #42 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #41)
> (In reply to Lukas Grätz from comment #40)
> > It seems that the reason for <optimized out> is ultimately -Og, not this
> > patch. See Bug 78685.
> 
> No.  When PR78685 would be fixed by adding artificial hidden uses of
> variables at the end of their scopes, this bug would trigger far more often.
> The vars would be live across the calls, so if there would be callee-saved
> registers available, the compiler
> would use them to hold the variables across the calls.  And this bug would
> break that.

It could be done that way. But I think a better fix for PR78685 would be to
save the function parameter values to the stack (and than this problem will not
trigger that often). For the following reasons:

(1) Timing for push and mov instructions are similar, so the execution speed
wouldn't be much affected.

(2) A callee needs to somehow restore callee-saved registers, but only if it
returns. So the calling conventions cannot guarantee that callee-saved
registers are saved somewhere for noreturn functions. But of course, if you
disregard this optimization, this would not trigger that often.

(3) Potential register pressure when saving additional variables to
callee-saved registers: If the execution itself no longer needs the value of a
function parameter, there is no need to hold it in a (callee-saved) register
accross calls for a quick access. The stack is sufficient for accessing the
values with the debugger.

(4) The entry values of function parameters should be more helpful, not some
later values. E.g., for

    int foo(int i) {
        if (i == 42) { h(); }
        i = 7;
        bar();
    }

we would be more interested in the original value of "i" and not the later
value "i = 7" as saved by "artificial hidden uses of variables at the end of
their scopes". By saving original values to the stack before they are modified,
we can keep inspecting the original values.

The helpful backtrace from within bar() could be:

#1   bar()
#2   foo(i@entry=42)

The other version would be a bit counter-intuitive, when the argument to foo
really was i=42:

#1   bar()
#2   foo(i=7)

Btw., function parameters are not normally part of the backtrace (this is just
a nice gdb feature), see Wikipedia:

https://en.wikipedia.org/wiki/Stack_trace

> Anyway, I've posted 
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646649.html
> patch which will not revert the #c15/#c24 changes, but guard them with a
> non-default option.  People who don't care about the harder debugging can
> use that option in their code, but widely used shared libraries with
> noreturn entrypoints will no longer screw up the debugging for all the
> packages that use them.

Yes, it took me long, but I agree, it would be better to not worsen debugging
experience.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #43 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Lukas Grätz from comment #42)
> (In reply to Jakub Jelinek from comment #41)
> > 
> > No.  When PR78685 would be fixed by adding artificial hidden uses of
> > variables at the end of their scopes, this bug would trigger far more often.
> > The vars would be live across the calls, so if there would be callee-saved
> > registers available, the compiler
> > would use them to hold the variables across the calls.  And this bug would
> > break that.
> 
> It could be done that way. But I think a better fix for PR78685 would be to
> save the function parameter values to the stack (and than this problem will
> not trigger that often). For the following reasons:
> 


Just to be complete with the arguments:

(5) Artificial hidden uses of variables at the end of their scopes would not
always help when variables are overwritten. For example:

int main (int argc, char **argv) {
    if (argc == 42) { h(); }
    might_not_return(0);
    argc = bar();
    // here would be the hidden use of argc and argv
}

The "artificial hidden use" approach would only save the last value of argc,
here the result of bar() in line 4 and not the argument argc. The argument
value of argc is not used from line 3 on. So that approach would still produce
a backtrace with argc=<optimized out>, something like:

#1 might_not_return(i=0)
#2 main (argc=<optimized out>, argv=0x7fffffffe0)

(6) When the goal is just to have a more helpful gdb bt output, then we don't
need to save any variables other than function parameters. In the original
example in Bug 78685 and Comment 28 here, this seemed to be the main goal, to
get gdb bt more conclusive. If interested in other variable values, too, -O0
might be better then trying hard to patch -Og to save all variable values.

(7) Bug 78685 is for x86-64 with -Og. For 32 bit x86 with -Og, we don't run
into that problem: there are no <optimized out> function parameters, since they
are already on the stack by the 32 bit calling conventions. So saving
parameters on the stack for -Og on x86-64 and similar targets without
stack-parameters would just be consequent.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #44 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Tom Tromey from comment #39)
> (In reply to Lukas Grätz from comment #36)
> 
> > > #2  0x00000000004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > > d=<error reading variable: value has been optimized out>, 
> > >     e=<error reading variable: value has been optimized out>, f=<error
> > > reading variable: value has been optimized out>, g=48, h=49) at /tmp/1.c:38
> > 
> > 
> > I can confirm that. What bothers me, is the wording "d=<error .... optimized
> > out>" and not just "d=<optimized out>".
> 
> Could you file a gdb bug about this?  Preferably with some
> kind of test case?

Done. See:

https://sourceware.org/bugzilla/show_bug.cgi?id=31436

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[lukas.graetz@tu-darmstadt.de]

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

--- Comment #45 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Lukas Grätz from comment #9)
> > Well it is not my testcase. But I added backtracing and observed that the
> > printed backtrace is unchanged with your patch. The new
> > no_return_to_caller():
> 
> You haven't tried hard enough.
> Consider the testcase I've posted to the mailing list, built with -Og -g.
> It is artificial in that register pressure is increased artificially rather
> than coming from meaningful code, noipa attribute is used heavily instead of
> functions being too large or in different TUs, and optimize attribute used
> instead of the noreturn function sitting in a different library, built there
> with -O2, while user program say with -Og.


I found a

        movq    %rsp, %rbp
        .cfi_def_cfa_register 6

in the assembler output of your example code in function qux(). After that, the
value of %rsp is only reconstructable with %rbp. Because there is some alloca
with unkown size at compile time in qux(), we could not reconstruct %rsp
otherwise. So I was ultimately wrong, and the value of %rbp would be needed to
construct the backtrace in some cases. So the only option to still get the
backtrace is to apply your patch to save %rbp (given that .cfi_def_cfa_register
always points to %rbp).

But I guess you know that already.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #46 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:a307a26e8b392ba65edfdae15489556b7701db81

commit r14-9387-ga307a26e8b392ba65edfdae15489556b7701db81
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 8 09:18:19 2024 +0100

    i386: Guard noreturn no-callee-saved-registers optimization with
-mnoreturn-no-callee-saved-registers [PR38534]

    The following patch hides the noreturn no_callee_saved_registers (except
bp)
    optimization with a not enabled by default option.
    The reason is that most noreturn functions should be called just once in a
    program (unless they are recursive or invoke longjmp or similar, for
exceptions
    we already punt), so it isn't that essential to save a few instructions in
their
    prologue, but more importantly because it interferes with debugging.
    And unlike most other optimizations, doesn't actually make it harder to
debug
    the given function, which can be solved by recompiling the given function
if
    it is too hard to debug, but makes it harder to debug the callers of that
    noreturn function.  Those can be from a different translation unit,
different
    binary or even different package, so if e.g. glibc abort needs to use all
    of the callee saved registers (%rbx, %rbp, %r12, %r13, %r14, %r15),
debugging
    any programs which abort will be harder because any DWARF expressions which
    use those registers will be optimized out, not just in the immediate
caller,
    but in other callers as well until some frame restores a particular
register
    from some stack slot.

    2024-03-08  Jakub Jelinek  <jakub@redhat.com>

            PR target/38534
            * config/i386/i386.opt (mnoreturn-no-callee-saved-registers): New
            option.
            * config/i386/i386-options.cc (ix86_set_func_type): Don't use
            TYPE_NO_CALLEE_SAVED_REGISTERS_EXCEPT_BP unless
            ix86_noreturn_no_callee_saved_registers is enabled.
            * doc/invoke.texi (-mnoreturn-no-callee-saved-registers): Document.

            * gcc.target/i386/pr38534-1.c: Add
-mnoreturn-no-callee-saved-registers
            to dg-options.
            * gcc.target/i386/pr38534-2.c: Likewise.
            * gcc.target/i386/pr38534-3.c: Likewise.
            * gcc.target/i386/pr38534-4.c: Likewise.
            * gcc.target/i386/pr38534-5.c: Likewise.
            * gcc.target/i386/pr38534-6.c: Likewise.
            * gcc.target/i386/pr114097-1.c: Likewise.
            * gcc.target/i386/stack-check-17.c: Likewise.

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[thutt at vmware dot com]

------- Comment #2 from thutt at vmware dot com  2008-12-16 14:03 -------
(In reply to comment #1)
> The reason why they are saved is so that you can have a good way of debugging
> noreturn functions.
> 

Can you please elaborate? How is saving these registers, which will never be
restored, going to make it easier to debug noreturn functions?

Can you please explain how the values in the saved registers are relevant
to the 'noreturn' function?

As far as I understand it, the callee saved registers are not used to pass
any information to the callee, so I don't understand how saving them makes
it easier to debug code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534

[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-12-15 23:26 -------
The reason why they are saved is so that you can have a good way of debugging
noreturn functions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534