From: Stefan Hajnoczi <stefanha@gmail.com>
To: vandersonmr <vandersonmr2@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Riku Voipio <riku.voipio@iki.fi>,
qemu-devel@nongnu.org, Laurent Vivier <laurent@vivier.eu>
Subject: Re: [Qemu-devel] [PATCH v2 1/2] accel/tcg: adding integration with linux perf
Date: Mon, 2 Sep 2019 11:07:55 +0100 [thread overview]
Message-ID: <20190902100755.GG9069@stefanha-x1.localdomain> (raw)
In-Reply-To: <20190830121903.17585-2-vandersonmr2@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]
On Fri, Aug 30, 2019 at 09:19:02AM -0300, vandersonmr wrote:
> This commit adds support to Linux Perf in order
> to be able to analyze qemu jitted code and
> also to able to see the TBs PC in it.
>
> When using "-perf" qemu creates a jitdump file in
> the current working directory. The file format
> specification can be found in:
> https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jitdump-specification.tx
Oops, the link is broken: .txt
> +struct jr_code_close {
> + struct jr_prefix p;
> +};
Unused?
> +
> +struct jr_code_move {
Unused?
> +static uint32_t get_e_machine(void)
> +{
> + uint32_t e_machine = EM_NONE;
> + Elf64_Ehdr elf_header;
> + FILE *exe = fopen("/proc/self/exe", "r");
> +
> + if (exe == NULL) {
> + return e_machine;
> + }
> +
> + if (fread(&elf_header, sizeof(Elf64_Ehdr), 1, exe) != 1) {
What if this is a 32-bit binary because QEMU was built for a 32-bit
host?
> + goto end;
> + }
> +
> + e_machine = elf_header.e_machine;
> +
> +end:
> + fclose(exe);
> + return e_machine;
> +}
> +
> +void start_jitdump_file(void)
> +{
> + gchar *dumpfile_name = g_strdup_printf("./jit-%d.dump", getpid());
You can now use g_autofree:
g_autofree gchar *dumpfile_name = g_strdup_printf(...);
and then the explicit g_free() isn't necessary anymore (and the memory
leak in the mmap error case is also solved).
> +void append_load_in_jitdump_file(TranslationBlock *tb)
> +{
> + gchar *func_name = g_strdup_printf("TB virt:0x"TARGET_FMT_lx, tb->pc);
> +
> + struct jr_code_load load_event;
> + load_event.p.id = JIT_CODE_LOAD;
> + load_event.p.total_size =
> + sizeof(struct jr_code_load) + strlen(func_name) + 1 + tb->tc.size;
> + load_event.p.timestamp = get_timestamp();
> + load_event.pid = getpid();
> + load_event.tid = syscall(SYS_gettid);
> + load_event.vma = tb->pc;
> + load_event.code_addr = (uint64_t) tb->tc.ptr;
> + load_event.code_size = tb->tc.size;
> + load_event.code_index = tb->pc;
> +
> + fwrite(&load_event, sizeof(struct jr_code_load), 1, dumpfile);
> + fwrite(func_name, strlen(func_name) + 1, 1, dumpfile);
> + fwrite(tb->tc.ptr, tb->tc.size, 1, dumpfile);
> +
> + g_free(func_name);
> + fflush(dumpfile);
> +}
I didn't see a reply to my question on the previous patch series:
"append_load_in_jitdump_file() calls fwrite() multiple times. What
guarantees they will not be interleaved when multiple threads call
this function?"
Does TCG ever throw away TBs and is it necessary to record this in the
file so perf knows about it?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-09-02 10:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 12:19 [Qemu-devel] [PATCH v2 0/2] Integrating qemu to Linux Perf vandersonmr
2019-08-30 12:19 ` [Qemu-devel] [PATCH v2 1/2] accel/tcg: adding integration with linux perf vandersonmr
2019-09-02 10:07 ` Stefan Hajnoczi [this message]
2019-10-02 18:55 ` Alex Bennée
2019-08-30 12:19 ` [Qemu-devel] [PATCH v2 2/2] tb-stats: adding TBStatistics info into perf dump vandersonmr
2019-09-02 9:41 ` [Qemu-devel] [PATCH v2 0/2] Integrating qemu to Linux Perf Stefan Hajnoczi
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=20190902100755.GG9069@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=laurent@vivier.eu \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
--cc=rth@twiddle.net \
--cc=vandersonmr2@gmail.com \
/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).