On Mon, 16 Jan 2023 at 22:36, Richard Henderson
<richard.hender...@linaro.org> wrote:
>
> From: Ilya Leoshkevich <i...@linux.ibm.com>
>
> Add ability to dump /tmp/perf-<pid>.map and jit-<pid>.dump.
> The first one allows the perf tool to map samples to each individual
> translation block. The second one adds the ability to resolve symbol
> names, line numbers and inspect JITed code.
>
> Example of use:
>
>     perf record qemu-x86_64 -perfmap ./a.out
>     perf report
>
> or
>
>     perf record -k 1 qemu-x86_64 -jitdump ./a.out
>     DEBUGINFOD_URLS= perf inject -j -i perf.data -o perf.data.jitted
>     perf report -i perf.data.jitted
>
> Co-developed-by: Vanderson M. do Rosario <vanderson...@gmail.com>
> Co-developed-by: Alex Bennée <alex.ben...@linaro.org>
> Signed-off-by: Ilya Leoshkevich <i...@linux.ibm.com>
> Message-Id: <20230112152013.125680-4-...@linux.ibm.com>
> Signed-off-by: Richard Henderson <richard.hender...@linaro.org>

Apparently this doesn't build with current head-of-trunk clang:
https://gitlab.com/qemu-project/qemu/-/issues/2970

> +struct debug_entry {
> +    uint64_t addr;
> +    int lineno;
> +    int discrim;
> +    const char name[];
> +};

> +struct jr_code_debug_info {
> +    struct jr_prefix p;
> +
> +    uint64_t code_addr;
> +    uint64_t nr_entry;
> +    struct debug_entry entries[];
> +};

> +/* Write a JIT_CODE_DEBUG_INFO jitdump entry. */
> +static void write_jr_code_debug_info(const void *start,
> +                                     const struct debuginfo_query *q,
> +                                     size_t icount)
> +{
> +    struct jr_code_debug_info rec;
> +    struct debug_entry ent;


../tcg/perf.c:250:24: error: default initialization of an object of
type 'struct debug_entry' with const member leaves the object
uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
  250 |     struct debug_entry ent;
      |                        ^
../tcg/perf.c:157:16: note: member 'name' declared 'const' here
  157 |     const char name[];
      |                ^

I don't understand what's going on with this flexible-array
name[] field: we never access it, and I don't see how we
can sensibly have an array of debug_entry structs in
jr_code_debug_info if the size of a debug_entry is variable.
I also don't see why we've declared it 'const'.

Anybody want to take a look at this?

thanks
-- PMM

Reply via email to