Re: [PATCH 00/12] Support gcov instrumentation
On 1/7/2022 4:25 pm, Sebastian Huber wrote: > On 01.07.22 08:22, Chris Johns wrote: I am encouraged by some of the generated code I have reviewed. I like what it does. >> I am a little lost with the difference between >> LIBRARY_OPTIMIZATION_FLAGS and >> OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference >> between >> them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can >> set >> from an INI file? > Currently the OPTIMIZATION_FLAGS are used for all code (code for > libraries and > code for tests). With this change you can build the libraries with -O0 > and > the > tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? >>> Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries >>> in >>> bsps and cpukit. >> Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming >> like >> BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was >> in >> the patch I would have understood exactly what they do. > > The BSP is just a library: librtemsbsp.a. I can split > LIBRARY_OPTIMIZATION_FLAGS > into BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS if this helps. I think it does. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 01.07.22 08:22, Chris Johns wrote: I am encouraged by some of the generated code I have reviewed. I like what it does. I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and code for tests). With this change you can build the libraries with -O0 and the tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in bsps and cpukit. Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming like BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was in the patch I would have understood exactly what they do. The BSP is just a library: librtemsbsp.a. I can split LIBRARY_OPTIMIZATION_FLAGS into BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS if this helps. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 1/7/2022 4:03 pm, Sebastian Huber wrote: > On 01.07.22 07:38, Chris Johns wrote: If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? >>> It is not per se specific to GCC. Maybe we should name it >>> RTEMS_COVERAGE_INSTRUMENTATION. >> What if another approach to instrumented coverage is developed? >> >> Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct. > > Ok, I rename it to RTEMS_GCOV_COVERAGE. Thanks. > The user can fine tune the build through the > LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and > COVERAGE_COMPILER_FLAGS, > COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? >>> Do you have to specify the compiler flags also during linking if you use >>> LTO? >> You add `-flto -ffat-lto-objects` to build the object files so they then >> contain >> the data the lto pass in the linker needs to optimise across the object >> files. > > The COVERAGE_LINKER_FLAGS are for the linking step. Are you required to pass > the > compiler flags during linking if you use LTO? Good question, I do not know. I think you can tall the linker to use LTO and to not use LTO. I do not know what the default mode of the linker is when presented with LTO enabled object files? The app I am building sets these flags in the cflags and those are passed to the linker. >> I am encouraged by some of the generated code I have reviewed. I like what it >> does. >> I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? >>> Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries >>> and >>> code for tests). With this change you can build the libraries with -O0 and >>> the >>> tests with -O2 for example. >> Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? > > Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in > bsps and cpukit. Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming like BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was in the patch I would have understood exactly what they do. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 01.07.22 07:38, Chris Johns wrote: If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? It is not per se specific to GCC. Maybe we should name it RTEMS_COVERAGE_INSTRUMENTATION. What if another approach to instrumented coverage is developed? Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct. Ok, I rename it to RTEMS_GCOV_COVERAGE. The user can fine tune the build through the LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and COVERAGE_COMPILER_FLAGS, COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? Do you have to specify the compiler flags also during linking if you use LTO? You add `-flto -ffat-lto-objects` to build the object files so they then contain the data the lto pass in the linker needs to optimise across the object files. The COVERAGE_LINKER_FLAGS are for the linking step. Are you required to pass the compiler flags during linking if you use LTO? I am encouraged by some of the generated code I have reviewed. I like what it does. I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and code for tests). With this change you can build the libraries with -O0 and the tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in bsps and cpukit. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 1/7/2022 3:07 pm, Sebastian Huber wrote: > On 01.07.22 03:19, Chris Johns wrote: >> On 29/6/2022 4:30 pm, Sebastian Huber wrote: >>> This patch set adds support to build the RTEMS libraries with gcov >>> instrumentation to get code and branch coverage. There are some >>> improvements >>> necessary in the build system to support different compiler flags for >>> libraries >>> and tests. In general, code coverage is enabled by the new RTEMS_COVERAGE >>> build configuration option. >> >> Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow >> provides? > > The covoar uses uninstrumented code, so these two approaches are orthogonal. > You > could even use both approaches at the same time. This makes little sense, but > you could do it. Agreed, it does not make sense. Someone new to RTEMS would not know what this all means and may think they need to enable the option for any type of coverage. >> If this enable is specific to GCC's gcov then maybe we should clearly label >> it >> as that and avoid overloading the term and any possible confusion that might >> bring. For example RTEMS_GCOV_CONVERGE? > > It is not per se specific to GCC. Maybe we should name it > RTEMS_COVERAGE_INSTRUMENTATION. What if another approach to instrumented coverage is developed? Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct. >>> The user can fine tune the build through the >>> LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and >>> COVERAGE_COMPILER_FLAGS, >>> COVERAGE_LINKER_FLAGS options. >> >> How would the LTO fat options be added? Would the pattern for >> COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? > > Do you have to specify the compiler flags also during linking if you use LTO? You add `-flto -ffat-lto-objects` to build the object files so they then contain the data the lto pass in the linker needs to optimise across the object files. I am encouraged by some of the generated code I have reviewed. I like what it does. >> I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and >> OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between >> them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set >> from an INI file? > > Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and > code for tests). With this change you can build the libraries with -O0 and > the > tests with -O2 for example. Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library? >> I think the changes to cppflags, cflags and cxxflags are nice and a great >> progression. >> >>> The gcov information is dumped after each test >>> case in a base64 encoded gcfn and gcda data stream. It looks like this: >>> >>> *** BEGIN OF GCOV INFO BASE64 *** >>> bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp >>> dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB >>> DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA >>> ... >>> srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc >>> ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7 >>> wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA= >>> *** END OF GCOV INFO BASE64 *** >>> >>> On the host you can decode the block and pipe it through the gcov-tool to >>> produce the *.gcda files. Example Python code: >>> >>> block = some regex stuff to get the block between the BEGIN/END OF ... >>> stream = base64.b64decode(block) >>> subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream) >> >> Nice. Could rtems-test detect this and then run that command if available? > > Yes, this could be an option. Another is to produce a JSON report and then > run a > second script. Sure. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 01.07.22 03:19, Chris Johns wrote: On 29/6/2022 4:30 pm, Sebastian Huber wrote: This patch set adds support to build the RTEMS libraries with gcov instrumentation to get code and branch coverage. There are some improvements necessary in the build system to support different compiler flags for libraries and tests. In general, code coverage is enabled by the new RTEMS_COVERAGE build configuration option. Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow provides? The covoar uses uninstrumented code, so these two approaches are orthogonal. You could even use both approaches at the same time. This makes little sense, but you could do it. If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? It is not per se specific to GCC. Maybe we should name it RTEMS_COVERAGE_INSTRUMENTATION. The user can fine tune the build through the LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and COVERAGE_COMPILER_FLAGS, COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? Do you have to specify the compiler flags also during linking if you use LTO? I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and code for tests). With this change you can build the libraries with -O0 and the tests with -O2 for example. I think the changes to cppflags, cflags and cxxflags are nice and a great progression. The gcov information is dumped after each test case in a base64 encoded gcfn and gcda data stream. It looks like this: *** BEGIN OF GCOV INFO BASE64 *** bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA ... srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7 wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA= *** END OF GCOV INFO BASE64 *** On the host you can decode the block and pipe it through the gcov-tool to produce the *.gcda files. Example Python code: block = some regex stuff to get the block between the BEGIN/END OF ... stream = base64.b64decode(block) subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream) Nice. Could rtems-test detect this and then run that command if available? Yes, this could be an option. Another is to produce a JSON report and then run a second script. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/12] Support gcov instrumentation
On 29/6/2022 4:30 pm, Sebastian Huber wrote: > This patch set adds support to build the RTEMS libraries with gcov > instrumentation to get code and branch coverage. There are some improvements > necessary in the build system to support different compiler flags for > libraries > and tests. In general, code coverage is enabled by the new RTEMS_COVERAGE > build configuration option. Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow provides? If this enable is specific to GCC's gcov then maybe we should clearly label it as that and avoid overloading the term and any possible confusion that might bring. For example RTEMS_GCOV_CONVERGE? > The user can fine tune the build through the > LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and > COVERAGE_COMPILER_FLAGS, > COVERAGE_LINKER_FLAGS options. How would the LTO fat options be added? Would the pattern for COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS? I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set from an INI file? I think the changes to cppflags, cflags and cxxflags are nice and a great progression. > The gcov information is dumped after each test > case in a base64 encoded gcfn and gcda data stream. It looks like this: > > *** BEGIN OF GCOV INFO BASE64 *** > bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp > dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB > DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA > ... > srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc > ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7 > wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA= > *** END OF GCOV INFO BASE64 *** > > On the host you can decode the block and pipe it through the gcov-tool to > produce the *.gcda files. Example Python code: > > block = some regex stuff to get the block between the BEGIN/END OF ... > stream = base64.b64decode(block) > subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream) Nice. Could rtems-test detect this and then run that command if available? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 00/12] Support gcov instrumentation
This patch set adds support to build the RTEMS libraries with gcov instrumentation to get code and branch coverage. There are some improvements necessary in the build system to support different compiler flags for libraries and tests. In general, code coverage is enabled by the new RTEMS_COVERAGE build configuration option. The user can fine tune the build through the LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and COVERAGE_COMPILER_FLAGS, COVERAGE_LINKER_FLAGS options. The gcov information is dumped after each test case in a base64 encoded gcfn and gcda data stream. It looks like this: *** BEGIN OF GCOV INFO BASE64 *** bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA ... srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7 wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA= *** END OF GCOV INFO BASE64 *** On the host you can decode the block and pipe it through the gcov-tool to produce the *.gcda files. Example Python code: block = some regex stuff to get the block between the BEGIN/END OF ... stream = base64.b64decode(block) subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream) Sebastian Huber (12): build: Add more flags to BuildItemContext build: Move BSP_INCLUDES split build: Fix identifier pattern build: Improve value substitution build: Add cppflags, cflags, cxxflags to groups build: Allow separate optimization flags gcov: Add fork(), etc. gcov wrappers gcov: Add functions to dump the gcov information gcov: Add wrapper to dump the gcov info build: Add RTEMS_COVERAGE option samples/minimum: Prevent a stack overflow libtests/crypt01: Avoid stack overflows cpukit/include/rtems/score/io.h | 4 + cpukit/include/rtems/test-info.h | 6 + cpukit/libcsupport/src/gcovfork.c | 94 ++ cpukit/libtest/testgcovbspreset.c | 54 cpukit/libtest/testgcovcpufatalhalt.c | 54 cpukit/libtest/testgcovdumpinfo.c | 66 ++ cpukit/score/src/iogcovdumpinfo.c | 101 +++ cpukit/score/src/iogcovdumpinfobase64.c | 111 spec/build/bsps/aarch64/a53/grp.yml | 3 + spec/build/bsps/aarch64/a72/grp.yml | 3 + spec/build/bsps/aarch64/grp.yml | 3 + spec/build/bsps/aarch64/xilinx-versal/grp.yml | 3 + .../bsps/aarch64/xilinx-versal/grp_qemu.yml | 3 + .../bsps/aarch64/xilinx-versal/grp_vck190.yml | 3 + spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml | 3 + .../bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml | 5 +- spec/build/bsps/arm/beagle/grp.yml| 3 + spec/build/bsps/arm/csb337/grp.yml| 3 + spec/build/bsps/arm/fvp/grp.yml | 3 + spec/build/bsps/arm/grp.yml | 3 + spec/build/bsps/arm/lm3s69xx/grp.yml | 3 + spec/build/bsps/arm/lpc176x/grp.yml | 3 + spec/build/bsps/arm/lpc24xx/grp.yml | 3 + spec/build/bsps/arm/lpc32xx/grp.yml | 3 + spec/build/bsps/arm/raspberrypi/grp.yml | 3 + spec/build/bsps/arm/rtl22xx/grp.yml | 3 + spec/build/bsps/arm/stm32f4/grp.yml | 3 + spec/build/bsps/arm/stm32h7/grp.yml | 3 + spec/build/bsps/arm/tms570/grp.yml| 3 + spec/build/bsps/arm/xilinx-zynq/grp.yml | 3 + spec/build/bsps/bfin/grp.yml | 3 + spec/build/bsps/bspopts.yml | 6 + spec/build/bsps/grpmake.yml | 3 + spec/build/bsps/i386/grp.yml | 3 + spec/build/bsps/i386/pc386/grp.yml| 3 + spec/build/bsps/lm32/grp.yml | 3 + spec/build/bsps/lm32/lm32_evr/grp.yml | 3 + spec/build/bsps/m68k/gen68360/grp.yml | 3 + spec/build/bsps/m68k/genmcf548x/grp.yml | 3 + spec/build/bsps/m68k/grp.yml | 3 + spec/build/bsps/m68k/mvme162/grp.yml | 3 + spec/build/bsps/microblaze/grp.yml| 3 + .../bsps/microblaze/microblaze_fpga/grp.yml | 3 + spec/build/bsps/mips/grp.yml | 3 + spec/build/bsps/optcflags.yml | 17 +++ spec/build/bsps/optincludes.yml | 1 + spec/build/bsps/optliboptflags.yml| 18 +++ spec/build/bsps/opto0.yml | 4 +- spec/build/bsps/opto1.yml | 4 +- spec/build/bsps/opto2.yml | 4 +- spec/build/bsps/optog.yml | 4 +- spec/build/bsps/optos.yml | 4 +- spec/build/bsps/opttestoptflags.yml | 18 +++ spec/build/bsps/or1k/grp.yml | 3 + spec/build/bsps
