public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/13158] New: bad unwind info as a result of sibcall
@ 2003-11-22  2:52 davidm at hpl dot hp dot com
  2003-11-22  2:54 ` [Bug c/13158] " davidm at hpl dot hp dot com
                   ` (21 more replies)
  0 siblings, 22 replies; 23+ messages in thread
From: davidm at hpl dot hp dot com @ 2003-11-22  2:52 UTC (permalink / raw)
  To: gcc-bugs

I have a distinct feeling of deja vue here, but I can't find any previous
discussion around this, so maybe it was never reported.  Anyhow, the problem is
that when GCC applies the sibcall optimization on ia64, it doesn't emit proper
unwind info.  Example:

$ cat bug.c
extern int foo (int);

int main (int argc, char **argv) {
  printf ("hello\n");
  return foo (argc);
}

int foo (int arg) {
  return 0;
}
$ gcc -v
Reading specs from /opt/gcc-pre3.4/lib/gcc/ia64-hp-linux/3.4/specs
Configured with:  : (reconfigured)  : (reconfigured)  : (reconfigured)  :
(reconfigured) 
Thread model: posix
gcc version 3.4 20031121 (experimental)
$ gcc -O2 -c bug.c
$ readelf -u bug.o

Unwind section '.IA_64.unwind' at offset 0xd0 contains 1 entries:

<main>: [0x10-0x70], info at +0x0
  v1, flags=0x0 (), len=8 bytes
    R2:prologue_gr(mask=[rp,ar.pfs],grsave=r33,rlen=5)
        P7:pfs_when(t=0)
        P7:rp_when(t=2)
    R1:body(rlen=13)
$ objdump -d bug.o | tail -19
0000000000000010 <main>:
  10:   0c 10 15 08 80 05       [MFI]       alloc r34=ar.pfs,5,4,0
  16:   00 00 00 02 00 20                   nop.f 0x0
  1c:   04 00 c4 00                         mov r33=b0
  20:   02 20 01 02 00 24       [MII]       addl r36=0,r1
  26:   30 02 04 00 42 00                   mov r35=r1;;
  2c:   00 00 04 00                         nop.i 0x0
  30:   1d 20 01 48 18 10       [MFB]       ld8 r36=[r36]
  36:   00 00 00 02 00 00                   nop.f 0x0
  3c:   08 00 00 50                         br.call.sptk.many b0=30;;
  40:   01 08 00 46 00 21       [MII]       mov r1=r35
  46:   00 08 05 80 03 00                   mov b0=r33
  4c:   20 02 aa 00                         mov.i ar.pfs=r34;;
  50:   1d 10 04 00 80 05       [MFB]       alloc r2=ar.pfs,1,0,0
  56:   00 00 00 02 00 00                   nop.f 0x0
  5c:   08 00 00 40                         br.many 50 <main+0x40>;;
  60:   1d 00 00 00 01 00       [MFB]       nop.m 0x0
  66:   00 00 00 00 00 00                   break.f 0x0
  6c:   00 00 00 20                         nop.b 0x0;;

The problem here is that the unwind info claims that even for the last six
instructions, ar.pfs is saved in r34 and rp in r33.  But after the "alloc"
instruction, those registers are not really valid anymore.  In particular, if
execution gets interrupted anywhere in the last six instructions, the contents
of those no-longer-allocated registers may get clobbered and at that point
unwinding may no longer be possible.

The best fix that I can think of would be to emit

       .restore sp

right before the instruction that restores ar.pfs (i.e., before the 7th-last 
instruction).  That would tell the unwinder that for the last six instructions,
rp and ar.pfs can be found in the default location (and nothing else has been
saved).  Of course, if a function has a memory stack frame, then the .restore sp
will be generated naturally for the instruction that restores the sp, so no such
dummy ".restore sp" directive would be needed.

-- 
           Summary: bad unwind info as a result of sibcall
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        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: ia64-hp-linux
  GCC host triplet: ia64-hp-linux
GCC target triplet: ia64-hp-linux


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


^ permalink raw reply	[flat|nested] 23+ messages in thread
end of thread, other threads:[~2005-04-20  2:00 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-22  2:52 [Bug c/13158] New: bad unwind info as a result of sibcall davidm at hpl dot hp dot com
2003-11-22  2:54 ` [Bug c/13158] " davidm at hpl dot hp dot com
2003-11-22  4:52 ` davidm at hpl dot hp dot com
2003-11-25  1:05 ` [Bug target/13158] " pinskia at gcc dot gnu dot org
2003-11-25  1:06 ` [Bug optimization/13158] " pinskia at gcc dot gnu dot org
2003-11-30  0:08 ` wilson at specifixinc dot com
2003-11-30  0:10 ` wilson at gcc dot gnu dot org
2004-05-13 13:56 ` [Bug target/13158] " davidm at hpl dot hp dot com
2004-05-14 17:24 ` wilson at specifixinc dot com
2004-10-22 16:25 ` davidm at hpl dot hp dot com
2004-10-27 22:44 ` cvs-commit at gcc dot gnu dot org
2004-10-27 23:16 ` wilson at gcc dot gnu dot org
2004-10-28  9:28 ` davidm at hpl dot hp dot com
2004-11-24 22:24 ` cvs-commit at gcc dot gnu dot org
2004-12-18 13:30 ` steven at gcc dot gnu dot org
2004-12-18 13:30 ` steven at gcc dot gnu dot org
2004-12-18 13:31 ` steven at gcc dot gnu dot org
2004-12-18 13:32 ` [Bug target/13158] [ia64] " steven at gcc dot gnu dot org
2005-01-13  5:57 ` cvs-commit at gcc dot gnu dot org
2005-01-14 19:16 ` cvs-commit at gcc dot gnu dot org
2005-01-14 19:45 ` cvs-commit at gcc dot gnu dot org
2005-01-14 19:51 ` wilson at gcc dot gnu dot org
2005-04-20  2:07 ` pinskia at gcc dot gnu dot org

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