From owner-freebsd-sparc Sun Oct 27 10: 7:44 2002 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F5E937B401 for ; Sun, 27 Oct 2002 10:07:43 -0800 (PST) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47DD343E4A for ; Sun, 27 Oct 2002 10:07:42 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g9RI7dx11029; Sun, 27 Oct 2002 10:07:39 -0800 (PST) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.5/8.12.5/Submit) id g9RI7dZC046984; Sun, 27 Oct 2002 10:07:39 -0800 (PST) (envelope-from jdp) Date: Sun, 27 Oct 2002 10:07:39 -0800 (PST) Message-Id: <200210271807.g9RI7dZC046984@vashon.polstra.com> To: sparc@freebsd.org From: John Polstra Cc: jake@locore.ca Subject: Re: Is the sparc64 stack segment executable? In-Reply-To: <20021026224039.F89245@locore.ca> References: <200210262328.g9QNSrkn045622@vashon.polstra.com> <20021026224039.F89245@locore.ca> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <20021026224039.F89245@locore.ca>, Jake Burkholder wrote: > > > Next question: Assuming the stack is not executable by default, would > > > it work for the application to make it executable using mprotect? > > > > Yes. > > Gcc is not generating the calls to mprotect. Its a simple fix, Yes, I saw the stuff in sol2.h that takes care of it. It sure is ugly, though. Every time you pass the address of a nested function, you have to make a system call. I suppose there must be some good reason why the stack isn't executable by default ... right? > I'll try to get it committed and get gcc on panther upgraded as > soon as I can. Thanks, but there's no rush (see below). To fix it were you just going to copy the definition of TRANSFER_FROM_TRAMPOLINE from into ? It would be good to fix it in gcc eventually, but don't rush to do it on my behalf. Modula-3 uses its own version of the gcc sources for its code generator, so fixing the system gcc won't make any difference there. I guess I can put the fix into the Modula-3 version to get it working -- or I can use a different approach. The original M3 code generator avoided the trampolines altogether, but that involved patching more of gcc. Up until now, I've managed to get by with simply adding new files to gcc-3.2. I haven't had to patch any of the stock source files. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message