From: arkadiy.ivanov@ispras.ru
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: Arkadiy <arkaisp2021@gmail.com>,
qemu-devel@nongnu.org, pavel.dovgaluk@ispras.ru
Subject: Re: [PATCH] contrib/plugins: add a drcov plugin
Date: Wed, 13 Oct 2021 11:55:30 +0300 [thread overview]
Message-ID: <48cc15d1532c9766bbef2f608eda12af@ispras.ru> (raw)
In-Reply-To: <87pmsawlph.fsf@linaro.org>
Alex Bennée писал 2021-10-12 13:36:
> Arkadiy <arkaisp2021@gmail.com> writes:
>
>> From: NDNF <arkaisp2021@gmail.com>
>>
>> This patch adds the ability to generate files in drcov format.
>> Primary goal this script is to have coverage
>> logfiles thatwork in Lighthouse.
>> Problems:
>> - The path to the executable file is not specified.
>
> I don't see a problem in introducing a plugin helper function to expose
> the path to the binary/kernel to the plugin.
>
>> - base, end, entry take incorrect values.
>> (Lighthouse + IDA Pro anyway work).
>
> What are they meant to be? Again we could add a helper.
>
>>
>> Signed-off-by: Ivanov Arkady <arkadiy.ivanov@ispras.ru>
>> ---
>> contrib/plugins/Makefile | 1 +
>> contrib/plugins/drcov.c | 112
>> +++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 113 insertions(+)
>> create mode 100644 contrib/plugins/drcov.c
>>
>> diff --git a/contrib/plugins/Makefile b/contrib/plugins/Makefile
>> index 7801b08b0d..0a681efeec 100644
>> --- a/contrib/plugins/Makefile
>> +++ b/contrib/plugins/Makefile
>> @@ -17,6 +17,7 @@ NAMES += hotblocks
>> NAMES += hotpages
>> NAMES += howvec
>> NAMES += lockstep
>> +NAMES += drcov
>>
>> SONAMES := $(addsuffix .so,$(addprefix lib,$(NAMES)))
>>
>> diff --git a/contrib/plugins/drcov.c b/contrib/plugins/drcov.c
>> new file mode 100644
>> index 0000000000..d6a7d131c0
>> --- /dev/null
>> +++ b/contrib/plugins/drcov.c
>> @@ -0,0 +1,112 @@
>> +/*
>> + * Copyright (C) 2021, Ivanov Arkady <arkadiy.ivanov@ispras.ru>
>> + *
>> + * Drcov - a DynamoRIO-based tool that collects coverage information
>> + * from a binary. Primary goal this script is to have coverage log
>> + * files that work in Lighthouse.
>> + *
>> + * License: GNU GPL, version 2 or later.
>> + * See the COPYING file in the top-level directory.
>> + */
>> +
>> +#include <inttypes.h>
>> +#include <assert.h>
>> +#include <stdlib.h>
>> +#include <inttypes.h>
>> +#include <string.h>
>> +#include <unistd.h>
>> +#include <stdio.h>
>> +#include <glib.h>
>> +
>> +#include <qemu-plugin.h>
>> +
>> +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
>> +
>> +static char header[] = "DRCOV VERSION: 2\n"
>> + "DRCOV FLAVOR: drcov-64\n"
>> + "Module Table: version 2, count 1\n"
>> + "Columns: id, base, end, entry, path\n";
>> +
>> +static FILE *fp;
>> +
>> +typedef struct {
>> + uint32_t start;
>> + uint16_t size;
>> + uint16_t mod_id;
>> +} bb_entry_t;
>> +
>> +static GSList *bbs;
>> +
>> +static void printfHeader()
>
> missing void in args.
>
>> +{
>> + g_autoptr(GString) head = g_string_new("");
>> + g_string_append(head, header);
>
> You could just initialise with your header:
>
> g_autoptr(GString) head = g_string_new(header);
>
>> + g_string_append_printf(head, "0, 0x%x, 0x%x, 0x%x, %s\n",
>> + 0, 0xffffffff, 0, "path");
>
> Why pass consts intro the printf instead of just appending the data as
> a string?
>
>> + g_string_append_printf(head, "BB Table: %d bbs\n",
>> g_slist_length(bbs));
>> + fwrite(head->str, sizeof(char), head->len, fp);
>> +}
>> +
>> +static void printfCharArray32(uint32_t data)
>> +{
>> + const uint8_t *bytes = (const uint8_t *)(&data);
>> + fwrite(bytes, sizeof(char), sizeof(data), fp);
>> +}
>> +
>> +static void printfCharArray16(uint16_t data)
>> +{
>> + const uint8_t *bytes = (const uint8_t *)(&data);
>> + fwrite(bytes, sizeof(char), sizeof(data), fp);
>> +}
>
> Can the above function names follow the QEMU house style please?
>
>> +
>> +
>> +static void printf_el(gpointer data, gpointer user_data)
>> +{
>> + bb_entry_t *bb = (bb_entry_t *)data;
>> + printfCharArray32(bb->start);
>> + printfCharArray16(bb->size);
>> + printfCharArray16(bb->mod_id);
>> +}
>> +
>> +static void plugin_exit(qemu_plugin_id_t id, void *p)
>> +{
>> + /* Print function */
>> + printfHeader();
>> + g_slist_foreach(bbs, printf_el, NULL);
>> +
>> + /* Clear */
>> + g_slist_free_full(bbs, &g_free);
>> + fclose(fp);
>> +}
>> +
>> +static void plugin_init(void)
>> +{
>> + fp = fopen("file.drcov.trace", "wb");
>
> Could we make this configurable and just have "file.drcov.trace" as the
> default if not set?
>
>> +}
>> +
>> +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb
>> *tb)
>> +{
>> + bb_entry_t *bb = g_new0(bb_entry_t, 1);
>> + uint64_t pc = qemu_plugin_tb_vaddr(tb);
>> +
>> + size_t n = qemu_plugin_tb_n_insns(tb);
>> + for (int i = 0; i < n; i++) {
>> + bb->size += qemu_plugin_insn_size(qemu_plugin_tb_get_insn(tb,
>> i));
>> + }
>> +
>> + bb->start = pc;
>> + bb->mod_id = 0;
>> + bbs = g_slist_append(bbs, bb);
>> +
>> +}
>
> I'm guessing this works in the simple case but beware that not all
> translations get executed. It might be better to as a install an actual
> tracer when the TB gets executed.
>
> Although most TBs run to completion there are cases where execution
> stops in them middle of TB. Generally this will be when a synchronous
> fault has occurred and we exit the block early, potentially
> regenerating
> a block at the PC the fault was at.
>
> The g_list_append should be protected by a mutex as translation can be
> multi-threaded (at least for system emulation).
>
>> +
>> +QEMU_PLUGIN_EXPORT
>> +int qemu_plugin_install(qemu_plugin_id_t id, const qemu_info_t *info,
>> + int argc, char **argv)
>> +{
>> + plugin_init();
>> +
>> + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans);
>> + qemu_plugin_register_atexit_cb(id, plugin_exit, NULL);
>> + return 0;
>> +}
>
> I'll happily take a v2 of this patch with the fixes outlined above.
>
> However I note the dynamorio pages talk about drcov2lcov which can
> convert to lcov data. Given the basics of code coverage will be the
> same
> it would be nice to see a re-factoring that would allow for multiple
> output formats so the user could select their preferred output as an
> option.
Could you tell me how to introduce the plugin helper function?
next prev parent reply other threads:[~2021-10-13 13:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 11:11 [PATCH] contrib/plugins: add a drcov plugin Arkadiy
2021-10-12 10:36 ` Alex Bennée
2021-10-13 8:55 ` arkadiy.ivanov [this message]
2021-10-13 9:13 ` Alex Bennée
2021-10-15 10:36 ` arkadiy.ivanov
2021-10-15 13:29 ` Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48cc15d1532c9766bbef2f608eda12af@ispras.ru \
--to=arkadiy.ivanov@ispras.ru \
--cc=alex.bennee@linaro.org \
--cc=arkaisp2021@gmail.com \
--cc=pavel.dovgaluk@ispras.ru \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).