public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/17455] New: syscall_linkage attribute  problem with sibling call optimization
@ 2004-09-13 11:29 eranian at hpl dot hp dot com
  2004-09-13 15:56 ` [Bug target/17455] " pinskia at gcc dot gnu dot org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: eranian at hpl dot hp dot com @ 2004-09-13 11:29 UTC (permalink / raw)
  To: gcc-bugs

We have found aproblem in the Linux/ia64 kernel related to sibling call
optimization and the syscall_linkage attribute. On this platform, the attribute
indicates that the function paramaters must be treated as read-only
by the compiler. Any modification requires making a copy. 

The following code give an example of the problem we are describing:

void
bar(void)
{
        printf("in syscall_trace\n");
}

void foo(long value) __attribute__((syscall_linkage));
void
foo (long value)
{
        bar();
}

Because foo() is so simple, and bar() is the last call, the compiler
generates a direct branch to bar as opposed to a normal function call.
The bar() function will return directly to the caller of foo().

The generated code at -O2 looks as follows:

0000000000000000 <bar>:
   0:   [MII]       alloc r33=ar.pfs,4,3,0
   6:               mov r32=b0
   c:               addl r35=0,r1
  10:   [MMI]       mov r34=r1;;
  16:               ld8 r35=[r35]
  1c:               nop.i 0x0
  20:   [MIB]       nop.m 0x0
  26:               nop.i 0x0
  2c:               br.call.sptk.many b0=20 <bar+0x20>;;
  30:   [MII]       mov r1=r34
  36:               mov.i ar.pfs=r33
  3c:               mov b0=r32
  40:   [MIB]       nop.m 0x0
  46:               nop.i 0x0
  4c:               br.ret.sptk.many b0;;

0000000000000050 <foo>:
  50:   [MMI]       alloc r16=ar.pfs,8,8,0;;
  56:               alloc r2=ar.pfs,8,0,0
  5c:               nop.i 0x0
  60:   [MIB]       nop.m 0x0
  66:               nop.i 0x0
  6c:               br.many 60 <foo+0x10>;;
  70:   [MFB]       nop.m 0x0
  76:               break.f 0x0
  7c:               nop.b 0x0;;

foo() cannot modify r32 (the first argument) because of the syscall_linkage
attibute. However bar() is allowed to. 

The sibling optimization makes a direct branch (br.many) to bar().
That branch does not actually "protect" r32 because no RSE movement occurs.
The alloc in bar() simply resizes its current frame but the same r32 that
was passed to foo() is also accessible and can be modified at will.

In functions with the syscall_linkage attribute, sibling call optimization
should not be done because it could break the guarantee offered by the
attribute.

-- 
           Summary: syscall_linkage attribute  problem with sibling call
                    optimization
           Product: gcc
           Version: 3.3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: eranian at hpl dot hp dot com
                CC: gcc-bugs at gcc dot gnu dot org,wilson at specifixinc
                    dot com
 GCC build triplet: ia64-linux
  GCC host triplet: ia64-linux
GCC target triplet: ia64-linux


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


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

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-13 11:29 [Bug c/17455] New: syscall_linkage attribute problem with sibling call optimization eranian at hpl dot hp dot com
2004-09-13 15:56 ` [Bug target/17455] " pinskia at gcc dot gnu dot org
2004-09-13 20:01 ` wilson at gcc dot gnu dot org
2004-09-13 20:02 ` wilson at gcc dot gnu dot org
2004-09-15 23:27 ` cvs-commit at gcc dot gnu dot org
2004-09-17 17:56 ` cvs-commit at gcc dot gnu dot org
2004-09-23 14:16 ` [Bug target/17455] [3.4 only] " pinskia at gcc dot gnu dot org
2004-11-01  0:47 ` mmitchel at gcc dot gnu dot org
2005-04-23  1:15 ` wilson 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).