19 thoughts on “Adding GNU Coverage Tools to Eclipse”

1. Pingback: GNU Code Coverage on Embedded Target with Eclipse Neon and ARM gcc 5 | MCU on Eclipse

2. Hi Erich – rather than copying arm-none-eabi-addr2line.exe to addr2line.exe etc. can’t you just change the names/prefixes of the tools under Window > Preferences > C/C++ > Profiling > Binutils Preferences?

   You can probably even preconfigure these by putting the settings in a plugin_customization.ini file referenced by eclipse.ini:

   http://blog.vogella.com/2012/08/07/eclipse-papercut-9-default-preference-settings-via-plugin_customization-ini-type-filter-example/

   org.eclipse.linuxtools.binutils/PREFKEY_ADDR2LINE_CMD=arm-none-eabi-addr2line
   org.eclipse.linuxtools.binutils/PREFKEY_CPPFILT_CMD=arm-none-eabi-c++filt
   org.eclipse.linuxtools.binutils/PREFKEY_NM_CMD=arm-none-eabi-nm
   org.eclipse.linuxtools.binutils/PREFKEY_STRINGS_CMD=arm-none-eabi-strings

   Hope this helps.
   Regards
   Tommy

   LikeLike

   Reply ↓

   • Hi Tommy,
     I considered changing the tool names in the Binutils preferences, but the problem is that this does not allow me to set the names for all the needed tools. So instead doing it in multiple places halfway, I decided to rename all of the tools. And that way it would not be a workspace setting which I would have to repeat for every workspace.

     LikeLike

     Reply ↓

     • OK – I didn’t notice that not all of the relevant tools can be renamed in the GUI. That seems like a bit of an oversight in the Gcov configuration GUI. I understand now why you do it the way that you do. Thanks.

       LikeLike

       Reply ↓

3. Hi,

   First of all, thank you for yours articles. They help a lot.
   I am trying to have semihosting with a Cortex-M3, Eclipse, GNU Embedded GCC (7-2017-q4 and try with 5_2-2015q4) and the SEGGER J-Link Embedded probe. The “printf” function works well. But the “fopen” function returns 0 and does not create the file on the host. Have you an idea ? It seems that this probe support the file semihosting.
   Note: I have set the rdimon.specs but not the “newlib-nano” library, because if I set it the “printf” function does not work.

   Thanks

   LikeLike

   Reply ↓

   • Thanks, good to hear that they are useful :-).
     Yes, the J-Link probes do support semihosting, and it is supported with the GNU Embedded GCC libraries. Make sure you use a recent (not old) J-Link driver (but I think Segger supports file I/O for more than 2 years).
     It works both with the newlib-nano and the newlib library. Nano is slower but uses less memory. One thought I have is that you should allocate plenty of heap and stack space (several KBytes) if you are using file I/O, same for using printf()).
     Maybe you were running into a heap/stack overflow? Allocate as much as you can for heap and stack.
     I hope this helps,
     Erich

     LikeLike

     Reply ↓

     • I have installed the last driver and firmware into the probe.
       The MCU Embedded Eclipse plugin gives only the option to use newlib-nano (–specs=nano.spec).
       I have allocated 32KB of heap and 32KB of stack space.

       LikeLike

       Reply ↓

       • If you do not specify the -specs=nano.spec, then it is using the newlib library, so this should work fine.

         LikeLike

       • Yes, in this case (only newlib), the printf works fine. But not this line: fopen(“c:\\tmp\\test.txt”, “w”) (the “c:\tmp” directory already exists). The fopen returns 0.
         Is it possible that it is a problem in the linker script ?
         No special pin of the JTAG cable is needed for file transfert ? (I believe that it is just a protocol with the GDB, right ?)

         LikeLike

       • In my coverage library I’m checking with the following function if file I/O works:
         
int gcov_check(void) {
#if GCOV_DO_COVERAGE
FILE *file = NULL;

         file = fopen ("c:\\tmp\\test.txt", "w");
if (file!=NULL) {
fputs("hello world with file I/O\r\n", file);
(void)fwrite("hello\r\n", sizeof("hello\r\n")-1, 1, file);
fclose(file);
return 1; /* ok */
}
return 0; /* failed */
#else
return 1; /* ok */
#endif
}

         I don’t think it is an issue with the linker script, and no special JTAG/SWD pin is needed for semihosting. It works the way the the printf() code calls a breakpoint exception which is catched by the debugger (the debugger has to be attached/connected).
         I hope this helps,
         Erich

         LikeLike

       • SEGGER sent me a answer :
         “As described, Semihosting is handled by the debugger, in this case GDB/GDB Server.
         Therefore the actual implementation and available commands as well as the expected target behavior is dependent on the debugger.
         The J-Link User Guide describes the common available Semihosting commands in general.

         For GDB Server SYS_RENAME and SYS_REMOVE are disabled for security reasons.
         You could otherwise, intended or not intended, severely mess up the debugger host.
         In the GDB Server you should have seen a message about this when you tried to execute those commands:
         “Semi hosting error: SYS_RENAME: Target tries to rename file. Declined for security reasons.”

         All other Semihosting commands are available and tested with GDB Server.”

         Have you some information about that ?

         Thanks

         LikeLike

       • That’s new to me. But it makes sense that they do not allow rename and delete. But these functions are not used by the gcov library, so this does not really matter? Have you tried my test code?

         LikeLiked by 1 person

       • I have used this article to activate semihosting: https://mcuoneclipse.com/2014/09/11/semihosting-with-gnu-arm-embedded-launchpad-and-gnu-arm-eclipse-debug-plugins/

         and this for gcov (the problem is with the gcov_check function): https://mcuoneclipse.com/2017/06/19/gnu-code-coverage-on-embedded-target-with-eclipse-neon-and-arm-gcc-5/

         LikeLiked by 1 person

       • That combination only creates files, reads them back and appends data to it. It does not delete or rename files.

         LikeLiked by 1 person

4. Pingback: FreeRTOS: how to End and Restart the Scheduler | MCU on Eclipse

5. hi Erich,

   I was trying implement code coverage for one of example projects in frdm-k64 sdk (ver 2.5). I was able to generate the .gcno files , but I get a message in console that the .gcda creation is skipped.

   The print is “profiling:C:\Users\Documents\MCUXpressoIDE_10.3.1_2233\workspace_2\frdmk64f_hello_world\Debug/source/source_file.gcda:Skip”

   LikeLike

   Reply ↓

   • I have never seen such a message. But your path to the soruce file(s) seems a bit long. Can you use a shorter path for your project?
     I hope this helps,
     Erich

     LikeLike

     Reply ↓

6. Pingback: Tutorial: GNU Coverage with MCUXpresso IDE | MCU on Eclipse

7. Pingback: Tutorial: GNU gcov Coverage with the NXP i.MX RT1064 | MCU on Eclipse

This site uses Akismet to reduce spam. Learn how your comment data is processed.