public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "davidm at hpl dot hp dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/18010] New: bad unwind info due to multiple returns (missing epilogue) Date: Fri, 15 Oct 2004 11:14:00 -0000 [thread overview] Message-ID: <20041015111408.18010.davidm@hpl.hp.com> (raw) It appears there is a long-standing and quite nasty bug in GCC. I believe all versions of GCC which allow for reordering of basic-blocks are affected. In the example I attached, func has two epilogues, but the unwind info looks like this: <func>: [0x0-0x1d0], info at +0x0 v1, flags=0x0 (), len=32 bytes R2:prologue_gr(mask=[rp,ar.pfs],grsave=r37,rlen=11) P7:pfs_when(t=0) P7:mem_stack_f(t=1,size=4096) P7:pr_when(t=2) P3:pr_gr(reg=r40) P7:lc_when(t=7) P3:lc_gr(reg=r41) P7:rp_when(t=10) R3:body(rlen=46) B1:label_state(label=1) B2:epilogue(t=1,ecount=0) R1:body(rlen=30) B1:copy_state(label=1) Note that there is only one "epilogue" directive. The stack-popping instruction in the second "body" region is not marked at all, meaning that the unwind info will be incorrect once the stack got popped in the second "body" region. It's easiest to reproduce this bug with a libunwind-enabled gdb: $ gcc -v 2>&1 | grep 'version' gcc version 3.4.1 $ gcc -O2 -Wall .test-ptrace-misc.c ident.c -o test-ptrace-misc $ gdb ./test-ptrace-misc (gdb) b 0x4000000000000aa2 # this should be the last instruction in func (gdb) r Starting program: /home/davidm/src/unwind/build-opt/tests/test-ptrace-misc Program received signal SIGUSR1, User defined signal 1. 0x20000000000ef042 in kill () from /lib/tls/libc.so.6.1 (gdb) c Continuing. Breakpoint 1, 0x4000000000000aa2 in func () (gdb) bt #0 0x4000000000000aa2 in func () #1 0x4000000000000970 in func () #2 0x4000000000002070 in bar () #3 0x0000000000000000 in ?? () #4 0x0000000000000000 in ?? () ...etc... (You can verify that gdb is picking up libunwind by starting it with environment variable LD_DEBUG set to "files"; you should see a line along the lines of: 16559: file=libunwind-ia64.so; generating link map while gdb is starting up.) To fix this bug, GCC should be emitting a ".restore sp" directive in front of every instruction which pops the stack-pointer. -- Summary: bad unwind info due to multiple returns (missing epilogue) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davidm at hpl dot hp dot com CC: davidm at hpl dot hp dot com,gcc-bugs at gcc dot gnu dot org,wilson at gcc dot gnu dot org GCC build triplet: ia64-hp-linux GCC host triplet: ia64-hp-linux GCC target triplet: ia64-hp-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18010
next reply other threads:[~2004-10-15 11:14 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-10-15 11:14 davidm at hpl dot hp dot com [this message] 2004-10-15 11:15 ` [Bug target/18010] " davidm at hpl dot hp dot com 2004-10-19 1:07 ` wilson at specifixinc dot com 2004-10-19 18:08 ` davidm at hpl dot hp dot com 2004-10-21 18:03 ` davidm at hpl dot hp dot com 2004-10-21 18:07 ` pinskia at gcc dot gnu dot org 2004-10-22 10:57 ` davidm at hpl dot hp dot com 2004-10-25 23:54 ` wilson at tuliptree dot org 2004-10-26 0:06 ` wilson at tuliptree dot org 2004-10-26 8:49 ` davidm at hpl dot hp dot com 2004-10-27 1:36 ` cvs-commit at gcc dot gnu dot org 2004-10-27 1:48 ` wilson at gcc dot gnu dot org 2004-10-27 11:05 ` davidm at hpl dot hp dot com 2004-10-27 19:51 ` wilson at tuliptree dot org 2004-10-28 1:16 ` wilson at tuliptree dot org 2004-10-28 9:24 ` davidm at hpl dot hp dot com 2004-10-29 22:00 ` wilson at tuliptree dot org 2004-11-04 18:07 ` davidm at hpl dot hp dot com 2004-11-24 22:24 ` cvs-commit at gcc dot gnu dot org
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=20041015111408.18010.davidm@hpl.hp.com \ --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).