From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29889 invoked by alias); 29 Nov 2006 15:05:31 -0000 Received: (qmail 29880 invoked by uid 22791); 29 Nov 2006 15:05:30 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Nov 2006 15:05:24 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kATF5Mdu012702 for ; Wed, 29 Nov 2006 10:05:22 -0500 Received: from zebedee.littlepinkcloud.COM (vpn-14-91.rdu.redhat.com [10.11.14.91]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kATF5Jaa020460; Wed, 29 Nov 2006 10:05:20 -0500 Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5) with ESMTP id kATF5HDx008080; Wed, 29 Nov 2006 15:05:18 GMT Received: (from aph@localhost) by littlepinkcloud.COM (8.13.6/8.13.5/Submit) id kATF5HQV008077; Wed, 29 Nov 2006 15:05:17 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17773.41389.31744.476497@zebedee.pink> Date: Wed, 29 Nov 2006 15:05:00 -0000 From: Andrew Haley To: Perry Smith Cc: MSX to GCC Subject: Re: alloca attribute? In-Reply-To: <23269E43-1DF4-4B12-B8F3-3B78FD0A526F@easesoftware.com> References: <553134A1-8235-419C-84C1-1D930765C45B@easesoftware.com> <17773.24231.982657.317830@zebedee.pink> <17773.38968.981878.222733@zebedee.pink> <23269E43-1DF4-4B12-B8F3-3B78FD0A526F@easesoftware.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-11/txt/msg00362.txt.bz2 Perry Smith writes: > On Nov 29, 2006, at 8:24 AM, Andrew Haley wrote: > > > Perry Smith writes: > >> > >> On Nov 29, 2006, at 4:19 AM, Andrew Haley wrote: > >> > >>> Perry Smith writes: > >> No, I did not. I thought it would be too big a task and I'm > >> willing to put a try/catch after the stack has been changed so the > >> unwind does not need to go through this. This may be naive. (See > >> more below). > > > > You'll need unwinder data, sooner or later. But let's leave it for > > later, it's not strictly relevant to what you need now. > > O.k. > > >> > >> But in optimized code, the compiler does not load r1 with r1(0). > >> It assumes that r1 has not changed, and it knows the size of the > >> stack frame, it just adds the size of the stack frame to r1. This > >> will be the same address if r1 has not been changed. > > > > Right. > > > >> It seems like (but I may be wrong), even with the DWARF unwinder > >> information, the compiler will still produce the code that adds the > >> size of the stack from to r1 to get r1 to point to the previous > >> stack frame instead of loading r1 with r1 (0). > > > > Sure, but why would it matter? Your newStack routine should do > > something like > > > > newStack: > > save caller registers somewhere > > load new stack and frame pointer > > call -- whatever it is you want to run on the new stack > > restore caller registers, including stack and frame pointer > > return > > > > so it should not metter how the caller of newStack uses its stack > > frame or what foo does. As long as you conform to the ABI you'll be > > OK. > > Ahh... I think I see your confusion. newStack does not call . > I could do that and it would probably be safer, easier. But > sometimes newStack would need to call foo(a) and other times it > would need to call foo(a, b), etc. I thought about using varargs > so that any foo that is called must take a varargs argument. That > approach, obviously, is doable but imposes several restriction. > > But then I hit upon this other idea (which may suck). newStack > simply mucks with the stack and returns back to testit (the routine > that calls newStack). You're right. It sucks. :-) > I wish I could include some graphics but I'll try to describe it > with words. No, you've explained it perfectly well, but trust me here: it's a really bad idea. gcc can eliminate the stack pointer to the frame pointer, as you have discovered. gcc can also save a pointer to a local area on the stack, and that can be of indeterminate size. So gcc might do this int a = 2; p = &a; // allocated on the stack newStack(); *p = 3; print a; And a, being on the new stack, would now be different from *p, which still points to the old stack. It can't possibly work. Andrew.