From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NObcK-0002P7-6s for mharc-grub-devel@gnu.org; Sat, 26 Dec 2009 13:43:56 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NObcI-0002Ot-BH for grub-devel@gnu.org; Sat, 26 Dec 2009 13:43:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NObcD-0002OI-M0 for grub-devel@gnu.org; Sat, 26 Dec 2009 13:43:53 -0500 Received: from [199.232.76.173] (port=43248 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NObcD-0002OF-H9 for grub-devel@gnu.org; Sat, 26 Dec 2009 13:43:49 -0500 Received: from iona.labri.fr ([147.210.8.143]:37076) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NObcD-0007Ed-5X for grub-devel@gnu.org; Sat, 26 Dec 2009 13:43:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by iona.labri.fr (Postfix) with ESMTP id 4534636B74 for ; Sat, 26 Dec 2009 19:43:46 +0100 (CET) X-Virus-Scanned: amavisd-new at labri.fr Received: from iona.labri.fr ([127.0.0.1]) by localhost (iona.labri.fr [127.0.0.1]) (amavisd-new, port 10027) with LMTP id IO1I-1FZhbp9 for ; Sat, 26 Dec 2009 19:43:46 +0100 (CET) Received: from [192.168.1.111] (c2433-1-88-160-112-182.fbx.proxad.net [88.160.112.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by iona.labri.fr (Postfix) with ESMTP id E9FE236B67 for ; Sat, 26 Dec 2009 19:43:45 +0100 (CET) Message-ID: <4B365961.8070005@labri.fr> Date: Sat, 26 Dec 2009 19:43:45 +0100 From: =?ISO-8859-1?Q?Gr=E9goire_Sutre?= Organization: CNRS / LaBRI User-Agent: Thunderbird 2.0.0.23 (X11/20091027) MIME-Version: 1.0 To: The development of GNU GRUB References: <4B32821F.6050607@labri.fr> <20091224221243.GT12122@thorin> In-Reply-To: <20091224221243.GT12122@thorin> Content-Type: multipart/mixed; boundary="------------010601020304050609000908" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: Non-static variables and nested function pointers [bug #28392] X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2009 18:43:54 -0000 This is a multi-part message in MIME format. --------------010601020304050609000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Robert Millan wrote: >=20 > The following snippet (kern/misc.c) comes to mind: >=20 > #ifdef NEED_ENABLE_EXECUTE_STACK > /* Some gcc versions generate a call to this function > in trampolines for nested functions. */ > void __enable_execute_stack (void *addr __attribute__ ((unused))) > { > } > #endif I was away from my email, sorry for the delay. I hunted this segfault down in the meantime, and I came to the same conclusion. If I remove `grub_CHECK_ENABLE_EXECUTE_STACK' from configure.ac then the segfault in grub-probe disappear. > We added this for NetBSD in fact. In that platform, GCC generates refe= rences > to this function, which are usually satisfied by libc, but we don't lin= k with > libc, so we made it happy with an empty stub. Yes, I realized that this was NetBSD specific from the archives of the=20 mailing list -- kind of ironic ;-) On my NetBSD/i386 5.0 system, if I compile the attached example, the=20 symbol __enable_execute_stack does indeed appear in the executable=20 (according to nm). This holds for gcc 4.1.3 (the system's default=20 compiler) and for gcc 4.4.1. And the symbol __enable_execute_stack is=20 found in libgcc_s.so.1. > But this is only supposed to happen when building real GRUB. For util/ > stuff, we should use the libc facility instead. Maybe that's not the c= ase? I guess that it's not the case: util programs that are linked with=20 kern/misc.c do not use the libc's __enable_execute_stack (if=20 NEED_ENABLE_EXECUTE_STACK is defined in config.h). In case that helps, and to continue the discussion regarding executable stack on NetBSD, I made a few experiments on i386 and amd64 on a simplified example (see below). From what I could read, NetBSD implements memory protection with PaX. * NetBSD/i386: | with dummy __enable_execute_stack | | no | yes | -----------------+-----------------+-----------------+ PaX MPROTECT off | ok | segfault | -----------------+-----------------+-----------------+ PaX MPROTECT on | segfault | segfault | -----------------+-----------------+-----------------+ However, in all four cases, there is no segfault if the variable j in main is declared static. And in that case, the generated=20 executable does not contain the symbol __enable_execute_stack (according=20 to nm). * NetBSD/amd64: in all four cases, no segfault. Also, on NetBSD/amd64, the segfault problem I experienced in grub-probe=20 completely disappears. Gr=E9goire --------------010601020304050609000908 Content-Type: text/x-csrc; name="nested.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nested.c" #include #ifdef BAD /* Some gcc versions generate a call to this function in trampolines for nested functions. */ void __enable_execute_stack (void *addr __attribute__ ((unused))) { } #endif int apply(void (*hook) (int *)) { int a = 0; hook(&a); hook(&a); return a; } int main (int argc, char *argv[]) { /* static */ int j = 5; int res; void hook(int *n) { *n = *n + j; j--; } res = apply(hook); printf("result: %d, j=%d\n", res, j); return 0; } --------------010601020304050609000908--