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/18748] New: first instruction in each procedure isn't unwindable
Date: Wed, 01 Dec 2004 02:42:00 -0000	[thread overview]
Message-ID: <20041201024157.18748.davidm@hpl.hp.com> (raw)

I'm reporting this against x86_64-suse-linux since that's where I noticed the
problem first, but I believe the issue affects all platforms which use DWARF
unwind-info.

The problem is that when looking up unwind info when the instruction-pointer
(IP) points to X, we're actually looking up (X-1) in the unwind tables.  The
motivation for this fudging is that X may never be reached (because of
non-return functions).  Unfortunately, for the first instruction in a procedure,
looking up (X-1) may cause us to find the unwind-info for the preceeding
function which, in general, will give wrong results.

I see only two possible solutions:

 (1) Change the compiler(s) so it emits a dummy (nop) instruction in front
     of each procedure and include that (never-to-be-executed) dummy-instruction
     as part of the unwind-info.

 (2) Stop the IP-fudging. This occasionally requires emitting a dummy (nop)
     instruction after invoking a no-return functions.

This problem can easily be reproduced by single-stepping through a program and
attempting to unwind after each instruction.  The libunwind [1] package contains
a test-case for this which can be invoked like this:

 tests/test-ptrace -c -n -t tests/test-ptrace-misc

In theory, this test should succeed with no error.  Due to the above bug, it
will fail to unwind whenever execution reaches the first instruction in a procedure.

   --david

[1] http://www.hpl.hp.com/research/linux/libunwind/

-- 
           Summary: first instruction in each procedure isn't unwindable
           Product: gcc
           Version: 3.3.3
            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: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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


             reply	other threads:[~2004-12-01  2:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-01  2:42 davidm at hpl dot hp dot com [this message]
2004-12-01  2:48 ` [Bug target/18748] " pinskia at gcc dot gnu dot org
2005-06-19 14:39 ` pinskia 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=20041201024157.18748.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).