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