> From: Martin Liška <mli...@suse.cz> > Sent: Thursday, June 20, 2019 9:49 AM
> I see. What about the following patch: > > $ ./gcc/xgcc -Bgcc /tmp/main.c --coverage -fprofile-note=/tmp/main.gcno $ > ls -l /tmp/main.gcno > -rw-r--r-- 1 marxin users 428 Jun 20 15:48 /tmp/main.gcno Thanks. That did the trick. Next, I will be looking at modifying GCC to do one or both of two things -- . put the coverage variables into a section named on the command line instead of .data. The .data section would remain the default. . when requested on the command line, initialize the instrumentation variables at run time instead of at compile time. Compile time would remain the default. I haven't looked into the implementation of either, but the former feels easy. The latter is much more useful for us, but I expect it is also significantly harder. My thinking is that I will implement the former and will look into how hard the latter is. Depending on the outcome / other demands on my time, I might implement it as well. Background (or why do I want this): Our use is embedded. We disallow .data. Specialized data, for example, read-only data or data that goes into a different named section, is allowed. (Part of why we disallow .data is that we support warm boot, not just cold boot.) If neither was implemented, then for files currently without .data, we could alter the linker script. This would mean that files with .data would be uninstrumentable. Not ideal. If the former was implemented, then any file which is not time critical nor containing code called by the instrumentation code would be instrumentable. If the latter was implemented, then that would facilitate clearing the data on demand. Since one of the goals is not just to collect coverage data but to also learn what coverage is provided by each test or collection of tests, that is greatly facilitated by being able to clear the accumulated results on demand. A cold boot would take 20-30 minutes and you might need to 'set up' the tests...
