From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16627 invoked by alias); 15 Oct 2002 18:22:31 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16614 invoked from network); 15 Oct 2002 18:22:30 -0000 Received: from unknown (HELO orac.acorntoolworks.com) (66.123.74.10) by sources.redhat.com with SMTP; 15 Oct 2002 18:22:30 -0000 Received: (from jtc@localhost) by orac.acorntoolworks.com (8.11.6/8.11.6) id g9FILxK08249; Tue, 15 Oct 2002 11:21:59 -0700 (PDT) To: Nathan Sidwell Cc: gcc@gcc.gnu.org Subject: Re: new edge coverage profiler on gcc 3.3 References: <3DA9280F.9070601@cse.unsw.edu.au> <20021013181921.GG6766@kam.mff.cuni.cz> <3DAACAA7.9020209@codesourcery.com> Reply-To: jtc@acorntoolworks.com From: jtc@acorntoolworks.com (J.T. Conklin) Date: Tue, 15 Oct 2002 11:55:00 -0000 In-Reply-To: <3DAACAA7.9020209@codesourcery.com> Message-ID: <87r8erbm0o.fsf@orac.acorntoolworks.com> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00846.txt.bz2 Nathan Sidwell writes: > (Separately) I think we should break them out of libgcc into a > libgcov, so that they work with a shared link of libgcc. We can have > a spec which turns -fcoverage into -lgcov. This is appropriate for > 3.4, but is it too for 3.3? While I've only been playing with coverage for a few days, I think a separate library for the coverage infrastructure code makes a lot of sense. Perhaps we need to go beyond a single -lgcov library that is automatically linked with -fcoverage though. Some of the processors I'd like to get coverage information from don't have access to nicities like filesystems, so information that is collected has to be proxied to the control plane, then later transfered to a workstation for analysis. I guess I'm saying that in addition to separating the coverage code into its own library, we mustn't preclude users from supplying their own versions. With that in mind, it would be nice if there was adequate documentation of the coverage API for users to write their own. --jtc -- J.T. Conklin