From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2463 invoked by alias); 29 Apr 2014 18:38:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 2332 invoked by uid 89); 29 Apr 2014 18:38:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS,URIBL_SBL autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: shepard.synsport.net Received: from mail.synsport.com (HELO shepard.synsport.net) (208.69.230.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 29 Apr 2014 18:38:21 +0000 Received: from [192.168.0.20] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 34AFD435C7; Tue, 29 Apr 2014 13:37:57 -0500 (CDT) Message-ID: <535FF173.2060008@marino.st> Date: Tue, 29 Apr 2014 18:50:00 -0000 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ian Lance Taylor CC: gcc-patches , libstdc++ , Binutils , gdb-patches@sourceware.org Subject: Re: [PING] Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly References: <5352D100.9040108@marino.st> <53541A34.7050908@marino.st> <535FC71E.8070406@marino.st> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg02007.txt.bz2 On 4/29/2014 19:23, Ian Lance Taylor wrote: > On Tue, Apr 29, 2014 at 11:37 AM, John Marino wrote: >> >> Does anyone have any issues with this set of patches to add support for >> the DragonFly targets? It's a blocker for other patches of mine that >> have a more general benefit, but this (relatively simple) one has to go >> in first. > > It's inconvenient, but patches are much more likely to be reviewed > when they cover a separate part of the tree, as different people > maintain different parts. I expect your libitm and libcilkrts could > be approved trivially if you send them separately. Hi Ian, I was trying to identify specific people (e.g. an libitm person) and have them approve specific files since they are trivial as you saw. I decided to keep the patch set as an atomic unit because it needs to be committed as a unit, and also because I assumed it provided the necessary context. > The change to include/libiberty.h is fine. thanks! > I don't understand the benefit of libgcc/enable-execute-stack-bsd.c. > The code seems the same as the existing > libgcc/enable-execute-stack-mprotect.c. All you are changing is > omitting need_enable_exec_stack. If you just drop the FreeBSD > constructor, you will get the behaviour you want. With the caveat that this patch is over 2 years old, I just took a look at both files. I would have not needed to modify this file at all for DragonFly. In fact, I seem to recall that I didn't modify it for DragonFly, but rather for FreeBSD. If I had to guess, it would be that I found mprotect() was needed regardless of value of kern.stackprot. I must have traced some test failures back to this. Which I guess that's what you mean - just delete the block between "#if defined __FreeBSD__" and the next #elif which should be equivalent. I can tweak the patch set to do that. And what about the dl_iterate_phdr changes? Do they look good to you? Thanks, John