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


             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: link
Be 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).