From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1501 invoked by alias); 12 Jan 2011 14:38:49 -0000 Received: (qmail 1474 invoked by uid 22791); 12 Jan 2011 14:38:47 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Jan 2011 14:38:42 +0000 Received: (qmail 21177 invoked from network); 12 Jan 2011 14:38:40 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Jan 2011 14:38:40 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.72) (envelope-from ) id 1Pd1qR-0004F7-HM; Wed, 12 Jan 2011 14:38:39 +0000 Date: Wed, 12 Jan 2011 14:38:00 -0000 From: "Joseph S. Myers" To: Robert Millan cc: gcc@gcc.gnu.org Subject: Re: kfreebsd-gnu etc. issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1152306461-1288629691-1294843119=:15800" Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-01/txt/msg00147.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1152306461-1288629691-1294843119=:15800 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-length: 2412 On Wed, 12 Jan 2011, Robert Millan wrote: > > * These configurations use file_end_indicate_exec_stack to use the > > =C2=A0PT_GNU_STACK convention. =C2=A0While some of the implementation o= f this > > =C2=A0is in the GNU linker and glibc, it also requires kernel support f= or > > =C2=A0correct operation. =C2=A0Do all these kernels support this conven= tion, or > > =C2=A0should this code actually be disabled for them in GCC and glibc? >=20 > I'm not familiar with PT_GNU_STACK. Does a working > _dl_make_stack_executable() in glibc [1] indicate it's supported? I think the glibc code is necessary but may not be sufficient; whatever=20 kernel support there is or isn't, glibc needs to know how the kernel will=20 have set things up (on Linux, based on PT_GNU_STACK for the dynamic=20 linker, I think) in order to adjust it based on the PT_GNU_STACK of the=20 executable and shared libraries. Probably it's possible to get this right= =20 without kernel support (if glibc does the right things at startup), in=20 which case we could consider this a GNU userspace convention. > The only thing I know for sure is that those 2 syscalls don't work. Is > there any possibility that linux-unwind.h is useful for GNU/kFreeBSD > in its current state? I don't see how it can be useful in its current state for any system using= =20 different syscall numbers. Maybe the code using a ucontext would be=20 relevant given code checking for different (kernel-dependent)=20 instructions. > I don't understand this code, but what I can do is confirm that disabling > linux-unwind.h doesn't cause any breakage. Then we could disable it > untill/unless someone more clued than me ports it to kFreeBSD. Would > this be ok? That makes sense to me. If disabled for non-Linux-kernel targets, the=20 REG_NAME abstraction may as well be removed as not actually being useful=20 at present. > > * A minor point: TARGET_VERSION, referring to Linux, is not overridden > > =C2=A0by these configurations. >=20 > Perhaps a common (or a fallback) string mentioning GNU and/or glibc > would fit. But where's this displayed anyway? In collect2 (only, for these targets; mips-tdump and mips-tfile also use=20 it). I've also suggested that we should eliminate TARGET_VERSION=20 completely (probably for 4.7) but while it's there, referring to Linux for= =20 these targets is wrong. --=20 Joseph S. Myers joseph@codesourcery.com= ---1152306461-1288629691-1294843119=:15800--