From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18355 invoked by alias); 12 Jan 2011 14:02:17 -0000 Received: (qmail 18345 invoked by uid 22791); 12 Jan 2011 14:02:16 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-iw0-f175.google.com (HELO mail-iw0-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Jan 2011 14:02:11 +0000 Received: by iwn8 with SMTP id 8so552422iwn.20 for ; Wed, 12 Jan 2011 06:02:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.199.212 with SMTP id et20mr1024624ibb.22.1294840929561; Wed, 12 Jan 2011 06:02:09 -0800 (PST) Received: by 10.231.5.153 with HTTP; Wed, 12 Jan 2011 06:02:09 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Jan 2011 14:02:00 -0000 Message-ID: Subject: Re: kfreebsd-gnu etc. issues From: Robert Millan To: "Joseph S. Myers" Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00143.txt.bz2 2011/1/1 Joseph S. Myers : > [...] I found > several possible problems with the configurations for *-kfreebsd-gnu, > *-knetbsd-gnu and *-kopensolaris-gnu. Ok. Unless indicated otherwise, my answers below apply to *-kfreebsd-gnu, which is the only in these 3 systems that is actively maintained. For the other two I wouldn't worry about either guessing or leaving them as-is. If minor breakage happens it's unlikely to bother anyone. > * The headers config/kfreebsd-gnu.h etc. override > =C2=A0GLIBC_DYNAMIC_LINKER. =C2=A0But the 64-bit configurations > =C2=A0x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to > =C2=A0use any header that would override GLIBC_DYNAMIC_LINKER32 and > =C2=A0GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h > =C2=A0actually uses. =C2=A0Thus those configurations would use Linux-spec= ific > =C2=A0dynamic linker settings, which seems unlikely to be as intended. It's not as intended. On amd64 we use /lib/ld.so.1 and /lib/ld-kfreebsd-x86-64.so.1. > * These configurations use file_end_indicate_exec_stack to use the > =C2=A0PT_GNU_STACK convention. =C2=A0While some of the implementation of = this > =C2=A0is in the GNU linker and glibc, it also requires kernel support for > =C2=A0correct operation. =C2=A0Do all these kernels support this conventi= on, or > =C2=A0should this code actually be disabled for them in GCC and glibc? I'm not familiar with PT_GNU_STACK. Does a working _dl_make_stack_executable() in glibc [1] indicate it's supported? [1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/dl-e= xecstack.c?revision=3D1685&view=3Dmarkup > * The kfreebsd-gnu and knetbsd-gnu configurations use linux-unwind.h > =C2=A0(kopensolaris-gnu disables this). =C2=A0They define REG_NAME to ada= pt > =C2=A0linux-unwind.h to their system headers. =C2=A0But linux-unwind.h al= so > =C2=A0contains hardcoded checks for the particular instructions, complete > =C2=A0with hardcoded Linux syscall numbers, in Linux signal trampolines. I'm sorry. It seems this would be my fault (I introduced this with the first kfreebsd-gnu port). > =C2=A0Do the FreeBSD and NetBSD kernels really use identical instructions? Definitely not. But it's strange we didn't notice, we've been using it for several years. > =C2=A0Does this code do anything useful on those systems? =C2=A0If it's u= seful > =C2=A0(possibly with some fixes) then linux-unwind.h ought to be renamed; 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 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? > * A minor point: TARGET_VERSION, referring to Linux, is not overridden > =C2=A0by these configurations. Perhaps a common (or a fallback) string mentioning GNU and/or glibc would fit. But where's this displayed anyway? --=20 Robert Millan