From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4947 invoked by alias); 8 May 2008 17:37:43 -0000 Received: (qmail 4939 invoked by uid 22791); 8 May 2008 17:37:42 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 May 2008 17:37:23 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id B960E983F1; Thu, 8 May 2008 17:37:21 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 94BCF98011; Thu, 8 May 2008 17:37:21 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JuA3U-0006zO-SU; Thu, 08 May 2008 13:37:20 -0400 Date: Thu, 08 May 2008 19:00:00 -0000 From: Daniel Jacobowitz To: Kees Cook Cc: gdb-patches@sourceware.org Subject: Re: status of PIE support? Message-ID: <20080508173720.GA26555@caradoc.them.org> Mail-Followup-To: Kees Cook , gdb-patches@sourceware.org References: <20080508054526.GG12850@outflux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080508054526.GG12850@outflux.net> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00283.txt.bz2 On Wed, May 07, 2008 at 10:45:26PM -0700, Kees Cook wrote: > Hello! I'm curious what the current status PIE support is? No status that I know of. No one has been working on it for FSF GDB. Jan may know more since he maintains the Red Hat packaging. > What would be required to get this code in shape for a commit? I'm > currently fairly unfamiliar with gdb internals, but I'm willing to > learn. :) My general rules for reviewing patches are: - they must conform to GNU style guidelines and include changelogs. This can be tedious, but is not hard - especially not if your editor supports GNU coding style :-) - large patches should be broken into separate logical units where reasonable (this is always a judgement call) - the submitter and any authors must have FSF copyright assignment - the submitter has to be able to justify any line of the patch that does not make sense to the reviewer Unfortunately, while that's not quite as strict as "you must understand every line", it's closely related: the more of it a reviewer has to go figure out on his own, the more work it is to review the patch, and the harder it will be to find someone with the time to do it. A good way to handle bits you don't understand is to remove them and see what breaks; often this isn't practical, but when it is it's a sign of good tests :-) -- Daniel Jacobowitz CodeSourcery