Peter Maydell <peter.mayd...@linaro.org> writes:
> On Sun, 25 Sept 2022 at 12:15, Richard Henderson
> <richard.hender...@linaro.org> wrote:
>>
>> Prepare for targets to be able to produce TBs that can
>> run in more than one virtual context.
>
>> -/* Similarly, but for logs. */
>> +/*
>> + * Similarly, but for logs. In this case, when the virtual pc
>> + * is not available, use the physical address.
>> + */
>> static inline target_ulong tb_pc_log(const TranslationBlock *tb)
>> {
>> +#if TARGET_TB_PCREL
>> + return tb->page_addr[0];
>> +#else
>> return tb->pc;
>> +#endif
>> }
>
> This is going to break previously working setups involving
> the "filter logging to a particular address range" and also
> anybody post-processing logfiles and expecting to see
> the virtual address in -d exec logging, I think.
To be honest I've never found -exec logging that useful for system
emulation (beyond check-tcg tests) because it just generates so much
data.
> For the exec logging, we surely must know the actual
> virtual PC at the point of TB execution -- we were
> previously just using tb->pc as a convenient architecture
> independent place to get that from, but should now do
> something else.
>
> For places where logging a virtual PC becomes meaningless,
> we should at least indicate whether we're logging a
> physaddr or a vaddr, because now depending on the config
> we might do either.
Yes we should extend the logging to say phys-pc or virt-pc
> For the range-filter stuff, I'm not sure what to do.
> Alex, any ideas?
>
> (I see the -dfilter option documentation doesn't say
> whether it's intending to work on physical or virtual
> addresses...)
I have a feeling for system emulation phys-pc is the most natural but we
could extend the filter spec to be explicit.
>
> thanks
> -- PMM
--
Alex Bennée
