summaryrefslogtreecommitdiff
path: root/src/lib/gcov-glue.c
AgeCommit message (Collapse)Author
2017-03-13src/lib: Fix spacingLee Leahy
Fix the following errors and warnings detected by checkpatch.pl: ERROR: spaces required around that '?' (ctx:WxV) ERROR: spaces required around that '=' (ctx:VxV) ERROR: spaces required around that '<' (ctx:VxV) ERROR: spaces required around that '+=' (ctx:VxV) ERROR: space required after that ',' (ctx:VxV) ERROR: space required before the open brace '{' ERROR: space required after that close brace '}' ERROR: need consistent spacing around '+' (ctx:WxV) ERROR: need consistent spacing around '*' (ctx:WxV) ERROR: need consistent spacing around '&' (ctx:VxW) ERROR: spaces required around that '?' (ctx:VxW) ERROR: spaces required around that ':' (ctx:VxW) ERROR: trailing whitespace ERROR: space prohibited before that '++' (ctx:WxO) ERROR: space prohibited before that ',' (ctx:WxW) ERROR: space prohibited after that '!' (ctx:BxW) ERROR: spaces prohibited around that '->' (ctx:VxW) ERROR: space prohibited after that '-' (ctx:WxW) WARNING: space prohibited before semicolon WARNING: unnecessary whitespace before a quoted newline WARNING: missing space after return type Note that lib/libgcov.c and lib/lzmadecode.c are providing false positives for ERROR: need consistent spacing around '*' (ctx:WxV) An example is: void __gcov_merge_add(gcov_type *counters __attribute__ ((unused)), unsigned int n_counters __attribute__ ((unused))) {} TEST=Build and run on Galileo Gen2 Change-Id: I0016327a5754018eaeb25bedf42338291632c7c1 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18733 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-12src/lib: Remove space between function name and (Lee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: space prohibited between function name and open parenthesis '(' TEST=Build and run on Galileo Gen2 Change-Id: I8f3c79302dc5eb1861ffb245617a27addf8653ef Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18731 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-03-09src/lib: Remove braces for single statementsLee Leahy
Fix the following warning detected by checkpatch.pl: WARNING: braces {} are not necessary for single statement blocks TEST=Build and run on Galileo Gen2 Change-Id: Ie4b41f6fb75142ddd75103a55e0347ed85e7e873 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18697 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Tested-by: build bot (Jenkins)
2017-03-09src/lib: Fix space between type, * and variable nameLee Leahy
Fix the following errors detected by checkpatch.pl: ERROR: "foo* bar" should be "foo *bar" ERROR: "(foo*)" should be "(foo *)" ERROR: "foo * const * bar" should be "foo * const *bar" TEST=Build and run on Galileo Gen2 Change-Id: I0d20ca360d8829f7d7670bacf0da4a0300bfb0c1 Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com> Reviewed-on: https://review.coreboot.org/18696 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2017-03-09src/lib: Remove spaces after ( and before )Lee Leahy
Fix the following errors detected by checkpatch.pl: ERROR: space prohibited after that open parenthesis '(' ERROR: space prohibited before that close parenthesis ')' TEST=Build and run on Galileo Gen2 Change-Id: I586c5731c080282080fe5ddf3ac82252cb35bdd4 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/18636 Tested-by: build bot (Jenkins) Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-02-02lib/gcov-glue.c: Remove trailing number from COVERAGE_MAGIC macroJean Lucas
The COVERAGE_MAGIC macro has a trailing `4' on it, which makes it a 64-bit large integer, as opposed to a 32-bit unsigned integer, as originally designated in `util/cbmem/cbmem.c'. Remove this number so building with CODE_COVERAGE will succeed. Change-Id: Ib5d7f2704a4c092c3eca6f62e219edb30950d793 Signed-off-by: Jean Lucas <jean@4ray.co> Reviewed-on: https://review.coreboot.org/13520 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-10-08lib/gcov-glue.c: Define macro `COVERAGE_MAGIC` and use itPaul Menzel
The macro is defined in `util/cbmem/cbmem.c` too, so do the same here, so that searching for that macro name shows all the usages. Change-Id: I52e9fa414fbbe2012bc6d00312db528efba3e564 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/11803 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-03-18bootstate: use structure pointers for scheduling callbacksAaron Durbin
The GCC 4.9.2 update showed that the boot_state_init_entry structures were being padded and assumed to be aligned in to an increased size. The bootstate scheduler for static entries, boot_state_schedule_static_entries(), was then calculating the wrong values within the array. To fix this just use a pointer to the boot_state_init_entry structure that needs to be scheduled. In addition to the previous issue noted above, the .bs_init section was sitting in the read only portion of the image while the fields within it need to be writable. Also, the boot_state_schedule_static_entries() was using symbol comparison to terminate a loop which in C can lead the compiler to always evaluate the loop at least once since the language spec indicates no 2 symbols can be the same value. Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8699 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2013-05-01coverage: use boot state callbacksAaron Durbin
Utilize the static boot state callback scheduling to initialize and tear down the coverage infrastructure at the appropriate points. The coverage initialization is performed at BS_PRE_DEVICE which is the earliest point a callback can be called. The tear down occurs at the 2 exit points of ramstage: OS resume and payload boot. Change-Id: Ie5ee51268e1f473f98fa517710a266e38dc01b6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3135 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08Fix compilation when coverage debugging is enabledStefan Reinauer
With CONFIG_DEBUG_COVERAGE enabled, the build currently fails with src/lib/gcov-glue.c: In function 'fseek': src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format] src/lib/gcov-glue.c:87:2: error: format '%d' expects argument of type 'int', but argument 4 has type 'long int' [-Werror=format] Change-Id: Iddaa601748c210d9dad06ae9dab2a3deaa635b2c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3032 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-12Implement GCC code coverage analysisStefan Reinauer
In order to provide some insight on what code is executed during coreboot's run time and how well our test scenarios work, this adds code coverage support to coreboot's ram stage. This should be easily adaptable for payloads, and maybe even romstage. See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for more information. To instrument coreboot, select CONFIG_COVERAGE ("Code coverage support") in Kconfig, and recompile coreboot. coreboot will then store its code coverage information into CBMEM, if possible. Then, run "cbmem -CV" as root on the target system running the instrumented coreboot binary. This will create a whole bunch of .gcda files that contain coverage information. Tar them up, copy them to your build system machine, and untar them. Then you can use your favorite coverage utility (gcov, lcov, ...) to visualize code coverage. For a sneak peak of what will expect you, please take a look at http://www.coreboot.org/~stepan/coreboot-coverage/ Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2052 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Martin Roth <martin@se-eng.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>