[Bug c/41990] New: Incorrect stack setup on x86_64

[Bug c/41990] New: Incorrect stack setup on x86_64

[cube at cubidou dot net]

Provided a somewhat specific set of local variables, and as long as the code of
the function doesn't make any other function calls, gcc will decrease %rsp but
an incorrect and too small value.  This leads to local variables being
corrupted when the execution is interrupted;  this happens notably in the
kernel where interrupts use the stack of the thread they interrupted.

The file that I will hopefully be able to attach to that report demonstrates
the issue, if you look at the assembler output.  With the function call
commented out, gcc sets up the stack that way:

        movq    %rsp, %rbp
        subq    $152, %rsp

and later access one of the local variables with:

        movl    $0, -272(%rbp,%rax,4)

When the function call is uncommented, the subq instruction here will correctly
substract 272 to %rsp.

I've compiled a 4.4.2 for the sole purpose of doing this bug report;  NetBSD
comes with 4.1.3 and that's where the bug was initially spotted.


-- 
           Summary: Incorrect stack setup on x86_64
           Product: gcc
           Version: 4.4.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: cube at cubidou dot net
 GCC build triplet: x86_64-unknown-netbsd4.99.60
  GCC host triplet: x86_64-unknown-netbsd4.99.60
GCC target triplet: x86_64-unknown-netbsd4.99.60


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

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

------- Comment #1 from cube at cubidou dot net  2009-11-08 20:27 -------
Created an attachment (id=18995)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18995&action=view)
Test case

This very simple C file will expose the bug.  In the assembler output, see how
only 152 is substracted to %rsp when the space taken by the variables
themselves is already 268 bytes.  Uncommenting the function call will make gcc
compute the correct value.


-- 


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

[Bug c/41990] Incorrect stack setup on x86_64

[pinskia at gmail dot com]

------- Comment #2 from pinskia at gmail dot com  2009-11-08 20:29 -------
Subject: Re:   New: Incorrect stack setup on x86_64

The x86_64 abi includes a red zone. So I doubt this a bug in gcc  
unless netbsd's abi does not match what gcc does.

Sent from my iPhone

On Nov 8, 2009, at 12:25 PM, "cube at cubidou dot net"
<gcc-bugzilla@gcc.gnu.org 
 > wrote:

> Provided a somewhat specific set of local variables, and as long as  
> the code of
> the function doesn't make any other function calls, gcc will  
> decrease %rsp but
> an incorrect and too small value.  This leads to local variables being
> corrupted when the execution is interrupted;  this happens notably  
> in the
> kernel where interrupts use the stack of the thread they interrupted.
>
> The file that I will hopefully be able to attach to that report  
> demonstrates
> the issue, if you look at the assembler output.  With the function  
> call
> commented out, gcc sets up the stack that way:
>
>        movq    %rsp, %rbp
>        subq    $152, %rsp
>
> and later access one of the local variables with:
>
>        movl    $0, -272(%rbp,%rax,4)
>
> When the function call is uncommented, the subq instruction here  
> will correctly
> substract 272 to %rsp.
>
> I've compiled a 4.4.2 for the sole purpose of doing this bug  
> report;  NetBSD
> comes with 4.1.3 and that's where the bug was initially spotted.
>
>
> -- 
>           Summary: Incorrect stack setup on x86_64
>           Product: gcc
>           Version: 4.4.2
>            Status: UNCONFIRMED
>          Severity: major
>          Priority: P3
>         Component: c
>        AssignedTo: unassigned at gcc dot gnu dot org
>        ReportedBy: cube at cubidou dot net
> GCC build triplet: x86_64-unknown-netbsd4.99.60
>  GCC host triplet: x86_64-unknown-netbsd4.99.60
> GCC target triplet: x86_64-unknown-netbsd4.99.60
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
>


-- 


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

Re: [Bug c/41990] New: Incorrect stack setup on x86_64

[Andrew Pinski]

The x86_64 abi includes a red zone. So I doubt this a bug in gcc  
unless netbsd's abi does not match what gcc does.

Sent from my iPhone

On Nov 8, 2009, at 12:25 PM, "cube at cubidou dot net" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

> Provided a somewhat specific set of local variables, and as long as  
> the code of
> the function doesn't make any other function calls, gcc will  
> decrease %rsp but
> an incorrect and too small value.  This leads to local variables being
> corrupted when the execution is interrupted;  this happens notably  
> in the
> kernel where interrupts use the stack of the thread they interrupted.
>
> The file that I will hopefully be able to attach to that report  
> demonstrates
> the issue, if you look at the assembler output.  With the function  
> call
> commented out, gcc sets up the stack that way:
>
>        movq    %rsp, %rbp
>        subq    $152, %rsp
>
> and later access one of the local variables with:
>
>        movl    $0, -272(%rbp,%rax,4)
>
> When the function call is uncommented, the subq instruction here  
> will correctly
> substract 272 to %rsp.
>
> I've compiled a 4.4.2 for the sole purpose of doing this bug  
> report;  NetBSD
> comes with 4.1.3 and that's where the bug was initially spotted.
>
>
> -- 
>           Summary: Incorrect stack setup on x86_64
>           Product: gcc
>           Version: 4.4.2
>            Status: UNCONFIRMED
>          Severity: major
>          Priority: P3
>         Component: c
>        AssignedTo: unassigned at gcc dot gnu dot org
>        ReportedBy: cube at cubidou dot net
> GCC build triplet: x86_64-unknown-netbsd4.99.60
>  GCC host triplet: x86_64-unknown-netbsd4.99.60
> GCC target triplet: x86_64-unknown-netbsd4.99.60
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
>

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

------- Comment #3 from cube at cubidou dot net  2009-11-08 20:37 -------
Subject: Re:  Incorrect stack setup on x86_64

On Sun, Nov 08, 2009 at 08:29:44PM -0000, pinskia at gmail dot com wrote:
> 
> 
> ------- Comment #2 from pinskia at gmail dot com  2009-11-08 20:29 -------
> Subject: Re:   New: Incorrect stack setup on x86_64
> 
> The x86_64 abi includes a red zone. So I doubt this a bug in gcc  
> unless netbsd's abi does not match what gcc does.

152 is too small even for the total size of the local variables (268 in
the attached test case).  How a red zone can even be considered in that
case?

> On Nov 8, 2009, at 12:25 PM, "cube at cubidou dot net"
> <gcc-bugzilla@gcc.gnu.org 
>  > wrote:
> 
> > Provided a somewhat specific set of local variables, and as long as  
> > the code of
> > the function doesn't make any other function calls, gcc will  
> > decrease %rsp but
> > an incorrect and too small value.  This leads to local variables being
> > corrupted when the execution is interrupted;  this happens notably  
> > in the
> > kernel where interrupts use the stack of the thread they interrupted.
> >
> > The file that I will hopefully be able to attach to that report  
> > demonstrates
> > the issue, if you look at the assembler output.  With the function  
> > call
> > commented out, gcc sets up the stack that way:
> >
> >        movq    %rsp, %rbp
> >        subq    $152, %rsp
> >
> > and later access one of the local variables with:
> >
> >        movl    $0, -272(%rbp,%rax,4)
> >
> > When the function call is uncommented, the subq instruction here  
> > will correctly
> > substract 272 to %rsp.
> >
> > I've compiled a 4.4.2 for the sole purpose of doing this bug  
> > report;  NetBSD
> > comes with 4.1.3 and that's where the bug was initially spotted.
> >
> >
> > -- 
> >           Summary: Incorrect stack setup on x86_64
> >           Product: gcc
> >           Version: 4.4.2
> >            Status: UNCONFIRMED
> >          Severity: major
> >          Priority: P3
> >         Component: c
> >        AssignedTo: unassigned at gcc dot gnu dot org
> >        ReportedBy: cube at cubidou dot net
> > GCC build triplet: x86_64-unknown-netbsd4.99.60
> >  GCC host triplet: x86_64-unknown-netbsd4.99.60
> > GCC target triplet: x86_64-unknown-netbsd4.99.60
> >
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
> >
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.


-- 


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

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

------- Comment #4 from cube at cubidou dot net  2009-11-08 20:38 -------
Subject: Re:  Incorrect stack setup on x86_64

On Sun, Nov 08, 2009 at 08:37:25PM -0000, cube at cubidou dot net wrote:
[...]
> 152 is too small even for the total size of the local variables (268 in

I meant 260 here.


-- 


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

[Bug c/41990] Incorrect stack setup on x86_64

[cube at cubidou dot net]

------- Comment #5 from cube at cubidou dot net  2009-11-08 20:56 -------
Ok, I get it now.  Not a gcc bug, we have to compile our kernel modules with
-fno-red-zone like the rest of the kernel.

Sorry for the noise.


-- 

cube at cubidou dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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