[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 40/43] contrib/plugins: extend execlog to track register c
From: |
Alex Bennée |
Subject: |
Re: [PATCH v2 40/43] contrib/plugins: extend execlog to track register changes |
Date: |
Thu, 11 Jan 2024 12:24:38 +0000 |
User-agent: |
mu4e 1.11.27; emacs 29.1 |
Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> writes:
> Hello Alex,
>
> just reporting below what might be a riscv only oddity (also applies to
> patch 41 but easier to report here).
>
> Le 03/01/2024 à 18:33, Alex Bennée a écrit :
>> With the new plugin register API we can now track changes to register
>> values. Currently the implementation is fairly dumb which will slow
>> down if a large number of register values are being tracked. This
>> could be improved by only instrumenting instructions which mention
>> registers we are interested in tracking.
>> Example usage:
>> ./qemu-aarch64 -D plugin.log -d plugin \
>> -cpu max,sve256=on \
>> -plugin contrib/plugins/libexeclog.so,reg=sp,reg=z\* \
>> ./tests/tcg/aarch64-linux-user/sha512-sve
>> will display in the execlog any changes to the stack pointer (sp)
>> and
>> the SVE Z registers.
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Cc: Akihiko Odaki <akihiko.odaki@daynix.com>
>> Based-On: <20231025093128.33116-19-akihiko.odaki@daynix.com>
>
>> +static registers_init(int vcpu_index)
>> +{
>> + GPtrArray *registers = g_ptr_array_new();
>> + g_autoptr(GArray) reg_list = qemu_plugin_get_registers(vcpu_index);
>> +
>> + if (reg_list && reg_list->len) {
>> + /*
>> + * Go through each register in the complete list and
>> + * see if we want to track it.
>> + */
>> + for (int r = 0; r < reg_list->len; r++) {
>> + qemu_plugin_reg_descriptor *rd = &g_array_index(
>> + reg_list, qemu_plugin_reg_descriptor, r);
>
> riscv csrs are not continously numbered and the dynamically generated gdb xml
> seems to follow that scheme.
> So the calls to Glib string functions output quite a few assertion
> warnings because for the non existing csrs rd->name is NULL (and there
> are a bit less than 4000 such cases for rv64g).
> Checking for NULL and then continue is a simple way to solve the issue, but
> I am not sure this is the proper way to proceed, as it might stand in the
> generation of the riscv xml description for gdb.
I think in this case it might be easier to not expose it to the plugin
user at all. Is the lack of names an omission? How does gdb see them?
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
[PATCH v2 34/43] hw/core/cpu: Remove gdb_get_dynamic_xml member, Alex Bennée, 2024/01/03
[PATCH v2 35/43] gdbstub: Add members to identify registers to GDBFeature, Alex Bennée, 2024/01/03
[PATCH v2 43/43] docs/devel: document some plugin assumptions, Alex Bennée, 2024/01/03
[PATCH v2 17/43] tests/unit: Bump test-aio-multithread test timeout to 2 minutes, Alex Bennée, 2024/01/03
[PATCH v2 25/43] target/riscv: Validate misa_mxl_max only once, Alex Bennée, 2024/01/03
[PATCH v2 33/43] gdbstub: Infer number of core registers from XML, Alex Bennée, 2024/01/03
Re: [PATCH v2 00/43] testing and plugin updates for 9.0 (pre-PR), Alex Bennée, 2024/01/11