From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8509 invoked by alias); 13 May 2011 15:58:38 -0000 Received: (qmail 8499 invoked by uid 22791); 13 May 2011 15:58:37 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 May 2011 15:58:23 +0000 Received: by one.firstfloor.org (Postfix, from userid 503) id 21D811A9803A; Fri, 13 May 2011 17:58:21 +0200 (CEST) Date: Fri, 13 May 2011 17:14:00 -0000 From: Andi Kleen To: Jan Hubicka Cc: Richard Guenther , Xinliang David Li , Rong Xu , reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org, andi@firstfloor.org Subject: Re: [google] support for building Linux kernel with FDO (issue4523061) Message-ID: <20110513155821.GQ6008@one.firstfloor.org> References: <20110513010336.E567FC2972@rong.mtv.corp.google.com> <20110513094342.GD31449@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110513094342.GD31449@atrey.karlin.mff.cuni.cz> User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2011-05/txt/msg00997.txt.bz2 On Fri, May 13, 2011 at 11:43:42AM +0200, Jan Hubicka wrote: > > On Fri, May 13, 2011 at 6:53 AM, Xinliang David Li wrote: > > > Ok for google/main. > > > > Seems to be very special and not appropriate for GCC trunk. Instead > > an adjusted copy providing the interface GCC needs should belong to > > the kernel tree. > Andi Kleen also did work in this direction. We probably should synchronize the > efforts. Yes, the in kernel gcov code -- which already has large parts of the gcov interface, but unfortunately for gcc 3 needs to be updated. This needs to be done inside the kernel tree though. I did some work on this to update, but my efforts fell a bit short. The resulting kernel was actually larger because I was missing some information. My variant didn't need the TLS changes because I just used atomic counters. I also ran into some problems with gcc when the information was not missing some TUs due to the way the information is collected. -Andi -- ak@linux.intel.com -- Speaking for myself only.