aboutsummaryrefslogtreecommitdiff
path: root/extract-gcov.c
AgeCommit message (Collapse)AuthorFilesLines
2018-03-09gcov: Another GCC, another gcov tweakStewart Smith1-0/+4
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2016-07-11Fix GCOV_COUNTERS ifdef logic for GCC 6.0Stewart Smith1-1/+1
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-12-03Fix up extract-gcov for gcc > 4.8Stewart Smith1-9/+22
The story of extract-gcov is not necessarily a pleasant one, involving GCC internals, padding of data structures, differences in data structures that are designed to change whenever GCC wants to and a strong desire to not implement a VFS in skiboot or some other streaming interface (and associated userspace and other such blergh). This patch makes us be all explicit about padding in the structures, enabling -Wpadding for extract-gcov.c. We also get all strict over the size of things and add support for gcc 5.1, which added an extra counter. There is likely GCC hacking in my future to make this a lot less fragile. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-09-08Fix possible passing of -1 to write() in extract-gcov.cStewart Smith1-0/+5
Just print an error and exit() instead Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-08-18Use target CC for __GNUC__ version defines in extract-gcovStewart Smith1-1/+2
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-29GCOV: Fix compilation errorVasant Hegde1-1/+1
On gcc v4.9.2 we are hitting below error. [ HOSTCC ] extract-gcov.c In file included from /usr/include/stdint.h:25:0, from /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdint.h:9, from /data/opensource/pkvm/skiboot/ccan/short_types/short_types.h:4, from extract-gcov.c:18: /usr/include/features.h:148:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ^ cc1: all warnings being treated as errors /data/opensource/pkvm/skiboot/Makefile.main:179: recipe for target 'extract-gcov' failed >From features.h header file: /* _BSD_SOURCE and _SVID_SOURCE are deprecated aliases for _DEFAULT_SOURCE. If _DEFAULT_SOURCE is present we do not issue a warning; the expectation is that the source is being transitioned to use the new macro. */ Hence replace _BSD_SOURCE with _DEFAULT_SOURCE. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> CC: Stewart Smith <stewart@linux.vnet.ibm.com> Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-06-24fix error handling and skiboot dump size in extract-gcov.cStewart Smith1-3/+16
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-25make extract-gcov usable with math from skiboot.mapStewart Smith1-4/+7
No longer need to parse the skiboot log to find out where data structures are. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
2015-05-15Add extract-gcov utility for extracting gcda from skiboot dumpStewart Smith1-0/+220
If you dump the (relocated) skiboot memory (2MB, from 0x30000000) and point extract-gcov at it, you'll get a bunch of gcda files extracted in pwd that you can then feed to gcov to get real usage data. This is a different approach than, say, the linux kernel, which when built with gcov provides a debugfs interface to the gcda files that you can just copy with normal userspace utilities. For skiboot, I have no desire to add a VFS style interface and since if you're dealing with GCOV+skiboot you should probably pretty well know what you're doing, parsing the gcov data structures in userspace from a dump of memory is actually not too bad. You can grab this memory from linux, FSP, mambo or any debug mechanism that lets you dump out a section of physical memory. Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
generated by cgit v1.1 at 2024-11-15 03:37:29 +0000