From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2770 invoked by alias); 20 Nov 2019 15:22:49 -0000 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 Received: (qmail 2763 invoked by uid 89); 20 Nov 2019 15:22:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=mercy, belief, sooner, feeling X-HELO: mx0b-00154904.pphosted.com Received: from mx0b-00154904.pphosted.com (HELO mx0b-00154904.pphosted.com) (148.163.137.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2019 15:22:39 +0000 Received: from pps.filterd (m0170394.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAKFF5nL003146; Wed, 20 Nov 2019 10:22:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emc.com; h=from : to : cc : subject : mime-version : content-type : date : message-id; s=smtpout1; bh=2jpei/wlugOjRv6HDSqbWgejPBXoYSohhietNZXYTVY=; b=OJSFIjGJP1BjLluPZ1boeq8BDRlbGL/Lc/uf52kU7eAbmK5t8DLLcP4BcsewzAIu5Na4 jennU8e8DX0dlMY7oR3G8WTVvjU+9BwsEewSBQ+9rvU2yPoRi6MjBYJ21SPQY/AYgFfX 0L/kEEncuprnqUfFvQW2pM0h5BaMf4G52EU11yCJkNGislwepIZd9PdkGQNr/3j45Rdv coGWleQDiWoIg20+olmDAb8af8f4NbC48SMHY5wkZUqIZdwRNgDwQazbBi50ZxUcpET5 N7Rqd1QpDF8bLc0pkwC5zo2dgdycpAVRCoqpdJ8n0qlwxQMdTT2WxaaU+SwSnhhJ8xr+ +g== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2wacj822m4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 10:22:35 -0500 Received: from pps.filterd (m0090351.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAKFHmxd032464; Wed, 20 Nov 2019 10:22:34 -0500 Received: from mailuogwdur.emc.com (mailuogwdur-nat.lss.emc.com [128.221.224.79] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2wcjujvsm9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 20 Nov 2019 10:22:34 -0500 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd55.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id xAKFL9uL029947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Nov 2019 10:22:32 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd55.lss.emc.com xAKFL9uL029947 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1574263352; bh=vY3KQxepUbeLaqpStt4ANFxGrcc=; h=From:To:cc:Subject:MIME-Version:Content-Type:Date:Message-ID; b=Jj6tvGBzAlY6oryuhv5HIe29qZvjp3ud4beNFyEnXpJcjmEM80UnkmzsAQ/drmVjn kOdiLdKC4nNyU545x8/LxujSgIp5SsbChH2gsJy6qhFfdNMYBGcW0DyihaA/i+flLA wFfNFQNYfOJ5Q5UfVheSXtECCVOl5XENP8uEYubM= Received: from mailsyshubprd55.lss.emc.com (mailhub.lss.emc.com [10.106.48.137]) by maildlpprd01.lss.emc.com (RSA Interceptor); Wed, 20 Nov 2019 10:14:12 -0500 Received: from usendtaylorx2l.lss.emc.com (d5170089.lss.emc.com [10.243.146.89]) by mailsyshubprd55.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id xAKFEBLt022674; Wed, 20 Nov 2019 10:14:12 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id CE2ED260455; Wed, 20 Nov 2019 10:14:04 -0500 (EST) From: David Taylor To: Martin =?utf-8?Q?Li=C5=A1ka?= cc: gcc@gcc.gnu.org, dtaylor@emc.com Subject: Re: GCC's instrumentation and the target environment MIME-Version: 1.0 Content-Type: text/plain Date: Wed, 20 Nov 2019 15:22:00 -0000 Message-ID: <20745.1574262844@usendtaylorx2l> X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd55.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00170.txt.bz2 Sorry for not responding sooner. Thanks Martin. Like Joel we have a third party solution to instrumentation. Part of my objection to the third party solution is freedom. There are customizations we would like, but not having source we're at the mercy of the vendor both for whether it gets done and the timing. Part of the objection is the massive amount of changes I had to make to our build system to integrate it and the resulting feeling of fragility. They are reportedly addressing the latter in a future release. By contrast, looking at GCC based instrumentation, the changes required to our build system are very small and easy. Part of my purpose in posting was the belief that this problem -- wanting to instrument embedded code -- is not uncommon and has likely been solved already. And the hope that one of the solvers would feel that their existing solution was in a good enough shape to contribute back. Or that someone would point out that there is already an existing {Free | Open} source solution that I am overlooking. Since no one has mentioned an existing solution, here is a first draft of a proposed solution to GCC instrumentation not playing well with embedded... NOTE: *NONE* of the following has been implemented as yet. I would ulimately like this to be something that once implemented would be considered for becoming part of standard GCC. So, if you see something that would impede that goal or if changed would improve its chances, please speak up. Add a new configure options --{with|without}-libgcov-standalone-env Default: without (i.e., hosted) Question: should hosted libgcov be the default for all configuration tuples? Or should it only be the default when there are headers? Or...? When standalone, when building libgcov.a files, suppress -Dinhibit_libc and add -DLIBGCOV_STANDALONE_ENV to the command line switches. Then in libgcov-driver.c, libgcov-driver-system.c, gcov-io.c, replace all calls of fopen with calls of __gcov_open_int fread __gcov_read_int fwrite __gcov_write_int fclose __gcov_close_int fseek __gcov_seek_int ftell __gcov_tell_int setbuf __gcov_setbuf_int Probably belongs inside __gcov_open_int instead of as a separate routine. getenv __gcov_getenv_int abort __gcov_abort_int When the application is 'the kernel' or 'the system', abort isn't really an option. fprintf __gcov_fprintf_int This is called in two places -- gcov_error and gcov_exit_open_gcda_file. The latter hard codes the stream as stderr; the former calls get_gcov_error_file to get the stream (which defaults to stderr but can be overridded via an environment variable). I think that get_gcov_error_file should be renamed to __gcov_get_error_file, be made non-static, and be called by gcov_exit_open_gcda_file instead of hard coding stderr. For that matter, I feel that gcov_exit_open_gcda_file should just call __gcov_error instead of doing it's own error reporting. And __gcov_get_error_file and __gcov_error should be a replacable routines as embedded systems might well have a different way of reporting errors. vfprintf __gcov_vfprintf_int If gcov_open_gcda_file is altered to call __gcov_error and __gcov_error becomes a replacable routine, then fprintf and vfprintf do not need to be wrapped. malloc __gcov_malloc_int free __gcov_free_int Embedded applications often do memory allocation differently. While I think that the above list is complete, I wouldn't be surprised if I missed one or two. Other than __gcov_open_int, there would be no conflict if the _int was left off the end. I put it on to emphasize that these routines were not meant to be called by the user, but rather are provided by the user. Some other naming convention might be better. There would be a new header file, included as appropriate. If the normal (hosted) build was in effect, then some new (potentially one line static inline) functions would be defined for each of the above functions that just call the expected standard libc function. If the embedded (standalone) build was in effect, then there would be extern declarations for each of the above, but *NO* definition -- the definition would be the reposibility of the application. Comments? David