All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: helge.hafting@aitel.hist.no, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, gcc@gcc.gnu.org
Subject: Re: [10 PATCHES] inline functions to avoid stack overflow
Date: Thu, 03 Jul 2008 21:12:18 +0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0807031708280.20244@engineering.redhat.com> (raw)
In-Reply-To: <20080701.214507.261426026.davem@davemloft.net>

On Tue, 1 Jul 2008, David Miller wrote:

> From: Mikulas Patocka <mpatocka@redhat.com>
> Date: Wed, 2 Jul 2008 00:39:35 -0400 (EDT)
>
>> 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 :-(
>
> Actually, I know for a fact that you have to have those slots there.
>
> A long time ago in the sparc64 kernel, in the trap entry code, I tried
> only giving 128 bytes of stack frame as the trap entry called into C
> code.  And it did not work, I had to put the 6 slots there.

The bad thing is that gcc can't use those slots optimally. If you have for 
example:

void f(int *x)
{
}

void g()
{
 	int a;
 	f(&a);
}

void h()
{
 	g();
}

Then the variable "a" can't be placed into one of the 6 implicit slots for 
g->f call (beacuse "f" may overwrite that slot). But "a" could be placed 
into one of those 6 slots that "h" allocates for "g" (because these slots 
are owned by "g"). But it isn't --- additional place is allocated for "a" 
:-/

Mikulas

WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: helge.hafting@aitel.hist.no, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, gcc@gcc.gnu.org
Subject: Re: [10 PATCHES] inline functions to avoid stack overflow
Date: Thu, 3 Jul 2008 17:12:18 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0807031708280.20244@engineering.redhat.com> (raw)
In-Reply-To: <20080701.214507.261426026.davem@davemloft.net>

On Tue, 1 Jul 2008, David Miller wrote:

> From: Mikulas Patocka <mpatocka@redhat.com>
> Date: Wed, 2 Jul 2008 00:39:35 -0400 (EDT)
>
>> 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 :-(
>
> Actually, I know for a fact that you have to have those slots there.
>
> A long time ago in the sparc64 kernel, in the trap entry code, I tried
> only giving 128 bytes of stack frame as the trap entry called into C
> code.  And it did not work, I had to put the 6 slots there.

The bad thing is that gcc can't use those slots optimally. If you have for 
example:

void f(int *x)
{
}

void g()
{
 	int a;
 	f(&a);
}

void h()
{
 	g();
}

Then the variable "a" can't be placed into one of the 6 implicit slots for 
g->f call (beacuse "f" may overwrite that slot). But "a" could be placed 
into one of those 6 slots that "h" allocates for "g" (because these slots 
are owned by "g"). But it isn't --- additional place is allocated for "a" 
:-/

Mikulas

  reply	other threads:[~2008-07-03 21:12 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24  5:54 [10 PATCHES] inline functions to avoid stack overflow Mikulas Patocka
2008-06-24  5:54 ` Mikulas Patocka
2008-06-24  5:55 ` [1/10 PATCH] inline __queue_work Mikulas Patocka
2008-06-24  5:55   ` Mikulas Patocka
2008-06-24  5:56   ` [2/10 PATCH] inline inline-generic_writepages.patch Mikulas Patocka
2008-06-24  5:56     ` Mikulas Patocka
2008-06-24  5:57   ` [3/10 PATCH] inline wake_up_bit Mikulas Patocka
2008-06-24  5:57     ` Mikulas Patocka
2008-06-25 14:17     ` Denys Vlasenko
2008-06-25 14:17       ` Denys Vlasenko
2008-06-25 14:36       ` Mikulas Patocka
2008-06-25 14:36         ` Mikulas Patocka
2008-06-25 15:24         ` Denys Vlasenko
2008-06-25 15:24           ` Denys Vlasenko
2008-06-25 16:01           ` Mikulas Patocka
2008-06-25 16:01             ` Mikulas Patocka
2008-06-25 20:37             ` Denys Vlasenko
2008-06-25 20:37               ` Denys Vlasenko
2008-06-26  0:28               ` David Miller
2008-06-26  0:28                 ` David Miller
2008-06-26  3:35                 ` Denys Vlasenko
2008-06-26  3:35                   ` Denys Vlasenko
2008-06-26  4:18                   ` David Miller
2008-06-26  4:18                     ` David Miller
2008-06-26 18:22                 ` Pavel Machek
2008-06-26 18:22                   ` Pavel Machek
2008-06-25 22:23           ` David Miller
2008-06-25 22:23             ` David Miller
2008-06-25 22:30       ` David Miller
2008-06-25 22:30         ` David Miller
2008-06-24  5:57   ` [4/10 PATCH] inline __wake_up_bit Mikulas Patocka
2008-06-24  5:57     ` Mikulas Patocka
2008-06-24  5:58   ` [5/10 PATCH] inline __wake_up Mikulas Patocka
2008-06-24  5:58     ` Mikulas Patocka
2008-06-24  5:59   ` [6/10 PATCH] inline default_wake_function Mikulas Patocka
2008-06-24  5:59     ` Mikulas Patocka
2008-06-24  5:59   ` [6/10 PATCH] inline autoremove_wake_function Mikulas Patocka
2008-06-24  5:59     ` Mikulas Patocka
2008-06-24  6:01   ` [8/10 PATCH] inline filemap_fdatawrite Mikulas Patocka
2008-06-24  6:01     ` Mikulas Patocka
2008-06-24  6:01   ` [9/10 PATCH] inline dm-kcopyd-inline-wake.patch Mikulas Patocka
2008-06-24  6:01     ` Mikulas Patocka
2008-06-24  6:03   ` [10/10 PATCH] inline dispatch_job Mikulas Patocka
2008-06-24  6:03     ` Mikulas Patocka
2008-06-24  6:06 ` [PATCH] limit irq nesting Mikulas Patocka
2008-06-24  6:06   ` Mikulas Patocka
2008-06-24  7:01 ` [10 PATCHES] inline functions to avoid stack overflow Ingo Molnar
2008-06-24  7:01   ` Ingo Molnar
     [not found] ` <486216E7.8000002@aitel.hist.no>
2008-06-25 12:53   ` Mikulas Patocka
2008-06-25 12:53     ` Mikulas Patocka
2008-06-25 22:09     ` David Miller
2008-06-25 22:09       ` David Miller
2008-06-26  6:32       ` Bart Van Assche
2008-06-26  6:32         ` Bart Van Assche
2008-06-26  9:06         ` David Miller
2008-06-26  9:06           ` David Miller
2008-07-02  4:39       ` Mikulas Patocka
2008-07-02  4:39         ` Mikulas Patocka
2008-07-02  4:45         ` David Miller
2008-07-02  4:45           ` David Miller
2008-07-03 21:12           ` Mikulas Patocka [this message]
2008-07-03 21:12             ` Mikulas Patocka

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=Pine.LNX.4.64.0807031708280.20244@engineering.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=davem@davemloft.net \
    --cc=gcc@gcc.gnu.org \
    --cc=helge.hafting@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sparclinux@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.