From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4162 invoked by alias); 29 Nov 2006 15:58:17 -0000 Received: (qmail 4151 invoked by uid 22791); 29 Nov 2006 15:58:16 -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:58:08 +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 kATFw6Y6025111 for ; Wed, 29 Nov 2006 10:58:06 -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 kATFw3sY022266; Wed, 29 Nov 2006 10:58:04 -0500 Received: from littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5) with ESMTP id kATFw18D008623; Wed, 29 Nov 2006 15:58:02 GMT Received: (from aph@localhost) by littlepinkcloud.COM (8.13.6/8.13.5/Submit) id kATFw08m008620; Wed, 29 Nov 2006 15:58:00 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17773.44551.954051.164855@zebedee.pink> Date: Wed, 29 Nov 2006 15:58:00 -0000 From: Andrew Haley To: Perry Smith Cc: MSX to GCC Subject: Re: alloca attribute? In-Reply-To: <8699198A-45DC-45BD-8D19-C6497EC60D38@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> <17773.41389.31744.476497@zebedee.pink> <8699198A-45DC-45BD-8D19-C6497EC60D38@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/msg00364.txt.bz2 Perry Smith writes: > On Nov 29, 2006, at 9:05 AM, Andrew Haley wrote: > > > Perry Smith writes: > >> On Nov 29, 2006, at 8:24 AM, Andrew Haley wrote: > >> > >>> Perry Smith writes: > >> 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. > > Ahh... I see. It took me a while to figure out what you were saying. > > Shoot! > > o.k. So if I go with the idea of newStack calling foo, will I need the > unwind stuff you mentioned before? I'm somewhat terrified of > mucking with that but I probably need to learn how it works anyhow. If you want to switch stacks, and you want to throw exceptions past the switch, you'll have to create unwinder data, regardless of how you do the stack switching. Sorry. If you catch all exceptions on the other side of the stack switch so that they don't propagate past the switch, you won't need unwinder data. > Is this what I need to read and understand? > http://www.codesourcery.com/cxx-abi/abi-eh.html > > Or... do you have any ideas of a completely different approach somehow? Well, I described how I thought it ought to work in a previous mail. > This is going to suck so bad... all of my external entry points > need to move the stack. I thought, briefly, gee, thats just the > five or so driver entry points. But then there is the interrupt > handler, iodone, timer routines, all sorts of nasty things. Moving the stack isn't at all unusual. Operating systems do it all the time. But you've got to do it right. Save the call-saved registers, load fp and sp to point to the new area, and go. Andrew.