[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 16/17] accel/tcg: Introduce TARGET_TB_PCREL
From: |
Alex Bennée |
Subject: |
Re: [PATCH v5 16/17] accel/tcg: Introduce TARGET_TB_PCREL |
Date: |
Fri, 30 Sep 2022 15:57:21 +0100 |
User-agent: |
mu4e 1.9.0; emacs 28.2.50 |
Peter Maydell <peter.maydell@linaro.org> writes:
> On Fri, 30 Sept 2022 at 14:23, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> > 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.
>
> It can be very useful for "give me a list of all the
> PC values where we executed an instruction", for shorter
> test cases. You can then (given several of these) look at
> where two runs diverge, and similar things. I use it,
> so please don't break it :-)
ack.
FWIW you can also do that with:
-plugin ./contrib/plugins/libexeclog.so,ifilter="instruction"
and avoid having to reduce a bunch of massive logs.
>
>> > 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.
>
> ...isn't it currently based on virtual addresses, though ?
Yes - or rather it only ever considered whatever was in tb->pc.
>
> -- PMM
--
Alex Bennée
[PATCH v5 17/17] accel/tcg: Split log_cpu_exec into inline and slow path, Richard Henderson, 2022/09/25
Re: [PATCH v5 00/17] tcg: CPUTLBEntryFull and TARGET_TB_PCREL, Richard Henderson, 2022/09/28