public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "lukas.graetz@tu-darmstadt.de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function Date: Tue, 27 Feb 2024 13:07:40 +0000 [thread overview] Message-ID: <bug-38534-4-5FYL6i3eze@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-38534-4@http.gcc.gnu.org/bugzilla/> 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.
next prev parent reply other threads:[~2024-02-27 13:07 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-38534-4@http.gcc.gnu.org/bugzilla/> 2011-11-07 0:15 ` js at alien8 dot de 2024-01-12 21:22 ` hjl.tools at gmail dot com 2024-01-13 6:05 ` sjames at gcc dot gnu.org 2024-01-14 12:05 ` lukas.graetz@tu-darmstadt.de 2024-01-14 12:08 ` lukas.graetz@tu-darmstadt.de 2024-01-14 14:12 ` hjl.tools at gmail dot com 2024-01-14 22:32 ` lukas.graetz@tu-darmstadt.de 2024-01-14 22:44 ` hjl.tools at gmail dot com 2024-01-14 22:54 ` lukas.graetz@tu-darmstadt.de 2024-01-15 10:22 ` lukas.graetz@tu-darmstadt.de 2024-01-15 10:49 ` lukas.graetz@tu-darmstadt.de 2024-01-15 12:23 ` lukas.graetz@tu-darmstadt.de 2024-01-27 12:19 ` cvs-commit at gcc dot gnu.org 2024-01-27 12:54 ` jakub at gcc dot gnu.org 2024-01-27 13:09 ` jakub at gcc dot gnu.org 2024-01-27 13:31 ` hjl.tools at gmail dot com 2024-01-27 13:45 ` jakub at gcc dot gnu.org 2024-01-27 13:47 ` jakub at gcc dot gnu.org 2024-01-27 15:05 ` aburgess at redhat dot com 2024-01-27 16:08 ` hjl.tools at gmail dot com 2024-01-27 20:42 ` hjl.tools at gmail dot com 2024-01-29 13:29 ` cvs-commit at gcc dot gnu.org 2024-02-01 12:23 ` lukas.graetz@tu-darmstadt.de 2024-02-01 12:43 ` jakub at gcc dot gnu.org 2024-02-01 14:40 ` lukas.graetz@tu-darmstadt.de 2024-02-27 10:18 ` jakub at gcc dot gnu.org 2024-02-27 12:17 ` lukas.graetz@tu-darmstadt.de 2024-02-27 12:32 ` jakub at gcc dot gnu.org 2024-02-27 13:07 ` lukas.graetz@tu-darmstadt.de [this message] 2024-02-27 13:17 ` jakub at gcc dot gnu.org 2024-02-27 13:38 ` lukas.graetz@tu-darmstadt.de 2024-02-27 14:03 ` jakub at gcc dot gnu.org 2024-02-27 14:39 ` jakub at gcc dot gnu.org 2024-02-27 17:00 ` lukas.graetz@tu-darmstadt.de 2024-02-27 17:10 ` jakub at gcc dot gnu.org 2024-02-27 18:15 ` lukas.graetz@tu-darmstadt.de 2024-02-27 23:54 ` tromey at gcc dot gnu.org 2024-02-28 8:09 ` lukas.graetz@tu-darmstadt.de 2024-02-28 8:15 ` jakub at gcc dot gnu.org 2024-02-28 9:43 ` lukas.graetz@tu-darmstadt.de 2024-02-28 13:31 ` lukas.graetz@tu-darmstadt.de 2024-02-29 17:56 ` lukas.graetz@tu-darmstadt.de 2024-02-29 20:12 ` lukas.graetz@tu-darmstadt.de 2024-03-08 8:30 ` cvs-commit at gcc dot gnu.org 2008-12-15 19:00 [Bug c/38534] New: " thutt at vmware dot com 2008-12-15 23:27 ` [Bug rtl-optimization/38534] " pinskia at gcc dot gnu dot org 2008-12-16 14:05 ` thutt at vmware dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-38534-4-5FYL6i3eze@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).