Re: trace_FOO_tcg bit-rotted?

[Alex Bennée]

Laurent Vivier <laurent@vivier.eu> writes:

> Le 06/04/2021 à 18:00, Alex Bennée a écrit :
>> Hi,
>> 
>> It's been awhile since I last played with this but I think we are
>> suffering from not having some test cases for tracing code
>> generation/execution in the tree. I tried adding a simple trace point to
>> see if I could track ERET calls:
>> 
>> --8<---------------cut here---------------start------------->8---
>> diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
>> index 0b42e53500..0d643f78fe 100644
>> --- a/target/arm/translate-a64.c
>> +++ b/target/arm/translate-a64.c
>> @@ -36,6 +36,7 @@
>>  #include "exec/log.h"
>>  
>>  #include "trace-tcg.h"
>> +#include "trace.h"
>>  #include "translate-a64.h"
>>  #include "qemu/atomic128.h"
>>  
>> @@ -2302,6 +2303,9 @@ static void disas_uncond_b_reg(DisasContext *s, 
>> uint32_t insn)
>>          default:
>>              goto do_unallocated;
>>          }
>> +
>> +        trace_eret_tcg(s->current_el, dst);
>> +
>>          if (tb_cflags(s->base.tb) & CF_USE_ICOUNT) {
>>              gen_io_start();
>>          }
>> diff --git a/target/arm/trace-events b/target/arm/trace-events
>> index 41c63d7570..2d4fca16a1 100644
>> --- a/target/arm/trace-events
>> +++ b/target/arm/trace-events
>> @@ -1,5 +1,10 @@
>>  # See docs/devel/tracing.txt for syntax documentation.
>>  
>> +# translate-a64.c
>> +# Mode: softmmu
>> +# Targets: TCG(aarch64-softmmu)
>> +tcg eret(int current_el, TCGv target_el) "trans_eret: from EL%d", 
>> "exec_eret: EL%d to EL%"PRId64
>
> If I read correctly, the name should be eret_tcg()
> And I'm not sure TCGv will be accepted as a parameter type, use
> uint64_t instead (and %PRIu64)

This was my confusion. I thought the trace-events file was prefixed with
tcg like guest_mem_before:

  vcpu tcg guest_mem_before(TCGv vaddr, uint16_t info) "info=%d", 
"vaddr=0x%016"PRIx64" info=%d"

and that signalled the tools to generate _trans, _exec and _tcg hooks in
the generated files. The trace code (see other patch) also has logic to
translate natural TCG types into the natives types as well signalling
which values are only visible for the _exec portion.

Maybe I'm over thinking this. Perhaps all the TCG tracing use cases are
just as easily supported with TCG plugins now and we should deprecate
this unused bit of complexity. I certainly understand the plugin
interactions better ;-)

>
> Thanks,
> Laurent


-- 
Alex Bennée