lkml.org 
[lkml]   [2008]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [10 PATCHES] inline functions to avoid stack overflow


    On Wed, 25 Jun 2008, David Miller wrote:

    > From: Mikulas Patocka <mpatocka@redhat.com>
    > Date: Wed, 25 Jun 2008 08:53:10 -0400 (EDT)
    >
    >> Even worse, gcc doesn't use these additional bytes. If you try this:
    >>
    >> extern void f(int *i);
    >> void g()
    >> {
    >> int a;
    >> f(&a);
    >> }
    >>
    >> , it allocates additional 16 bytes for the variable "a" (so there's total
    >> 208 bytes), even though it could place the variable into 48-byte
    >> ABI-mandated area that it inherited from the caller or into it's own
    >> 16-byte padding that it made when calling "f".
    >
    > The extra 16 bytes of space allocated is so that GCC can perform a
    > secondary reload of a quad floating point value. It always has to be
    > present, because we can't satisfy a secondary reload by emitting yet
    > another reload, it's the end of the possible level of recursions
    > allowed by the reload pass.
    >
    > GCC could be smart and eliminate that slot when it's not used, but
    > such a thing is not implemented yet.
    >
    > It would also require quite a bit of new code to determine cases
    > like you mention above, where the incoming arg slots from the
    > caller are unused, assuming this would be legal.
    >
    > And that legality is doubtful. We'd need to be careful because I
    > think the caller is allowed to assume that those slots are untouched
    > by the callee, and thus can be assumed to have whatever values the
    > caller put there even after the callee returns.

    The ABI is very vague about it. The V9 ABI just displays that 6-word space
    in a figure bug doesn't say anything about it's usage. The V8 ABI just
    says that "the function may write incoming arguments there". If it may
    write anything other, it is unknown --- probably yes, but it is not said
    in the document.

    The document nicely specifies who owns which registers, but doesn't say
    that about the stack space :-(

    Mikulas


    \
     
     \ /
      Last update: 2008-07-02 06:55    [W:2.251 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site