From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel@nongnu.org,
Richard Henderson <richard.henderson@linaro.org>,
devel@lists.libvirt.org, Thomas Huth <thuth@redhat.com>,
Mahmoud Mandour <ma.mandourr@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
David Hildenbrand <david@redhat.com>,
Ilya Leoshkevich <iii@linux.ibm.com>,
qemu-ppc@nongnu.org, Zhao Liu <zhao1.liu@intel.com>,
Yanan Wang <wangyanan55@huawei.com>,
Eduardo Habkost <eduardo@habkost.net>,
qemu-s390x@nongnu.org, Alexandre Iooss <erdnaxe@crans.org>,
Pierrick Bouvier <pierrick.bouvier@linaro.org>,
Nicholas Piggin <npiggin@gmail.com>,
Daniel Henrique Barboza <danielhb413@gmail.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Subject: Re: [PATCH 11/17] tests/tcg: only read/write 64 bit words on 64 bit systems
Date: Mon, 16 Sep 2024 09:41:34 +0100 [thread overview]
Message-ID: <875xqwgfcx.fsf@draig.linaro.org> (raw)
In-Reply-To: <c56f2b0b-3028-4b89-8289-e20519cdcdb7@linaro.org> ("Philippe Mathieu-Daudé"'s message of "Fri, 13 Sep 2024 22:15:40 +0200")
Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> On 13/9/24 19:26, Alex Bennée wrote:
>> While the compilers will generally happily synthesise a 64 bit value
>> for you on 32 bit systems it doesn't exercise anything on QEMU. It
>> also makes it hard to accurately compare the accesses to test_data
>> when instrumenting.
>> Message-Id: <20240910140733.4007719-21-alex.bennee@linaro.org>
>> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>> tests/tcg/multiarch/system/memory.c | 26 +++++++++++++++++++-------
>> 1 file changed, 19 insertions(+), 7 deletions(-)
>> diff --git a/tests/tcg/multiarch/system/memory.c
>> b/tests/tcg/multiarch/system/memory.c
>> index 8f2371975d..680dd4800b 100644
>> --- a/tests/tcg/multiarch/system/memory.c
>> +++ b/tests/tcg/multiarch/system/memory.c
>> @@ -163,6 +163,7 @@ static void init_test_data_u32(int offset)
>> ml_printf("done %d @ %p\n", i, ptr);
>> }
>> +#if __SIZEOF_POINTER__ == 8
>
>>= ? :)
Ahh I was confused by the email quoting. Do we actually have any systems
with bigger pointers or is this just for future proofing?
>
>> static void init_test_data_u64(int offset)
>> {
>> uint8_t count = 0;
>> @@ -187,6 +188,7 @@ static void init_test_data_u64(int offset)
>> }
>> ml_printf("done %d @ %p\n", i, ptr);
>> }
>> +#endif
>> static bool read_test_data_u16(int offset)
>> {
>> @@ -254,6 +256,7 @@ static bool read_test_data_u32(int offset)
>> return true;
>> }
>> +#if __SIZEOF_POINTER__ == 8
>> static bool read_test_data_u64(int offset)
>> {
>> uint64_t word, *ptr = (uint64_t *)&test_data[offset];
>> @@ -307,11 +310,16 @@ static bool read_test_data_u64(int offset)
>> ml_printf("done %d @ %p\n", i, ptr);
>> return true;
>> }
>> +#endif
>> /* Read the test data and verify at various offsets */
>> -read_ufn read_ufns[] = { read_test_data_u16,
>> - read_test_data_u32,
>> - read_test_data_u64 };
>> +read_ufn read_ufns[] = {
>> + read_test_data_u16,
>> + read_test_data_u32,
>> +#if __SIZEOF_POINTER__ == 8
>> + read_test_data_u64
>> +#endif
>> +};
>> bool do_unsigned_reads(int start_off)
>> {
>> @@ -476,10 +484,14 @@ bool do_signed_reads(bool neg_first)
>> return ok;
>> }
>> -init_ufn init_ufns[] = { init_test_data_u8,
>> - init_test_data_u16,
>> - init_test_data_u32,
>> - init_test_data_u64 };
>> +init_ufn init_ufns[] = {
>> + init_test_data_u8,
>> + init_test_data_u16,
>> + init_test_data_u32,
>> +#if __SIZEOF_POINTER__ == 8
>> + init_test_data_u64
>> +#endif
>> +};
>> int main(void)
>> {
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2024-09-16 8:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 17:26 [PATCH 00/17] tcg plugins pre-PR (deprecations, mem apis, contrib plugins) Alex Bennée
2024-09-13 17:26 ` [PATCH 01/17] deprecation: don't enable TCG plugins by default on 32 bit hosts Alex Bennée
2024-09-13 17:26 ` [PATCH 02/17] deprecation: don't enable TCG plugins by default with TCI Alex Bennée
2024-09-13 17:26 ` [PATCH 03/17] contrib/plugins: control flow plugin Alex Bennée
2024-09-13 17:26 ` [PATCH 04/17] plugins: save value during memory accesses Alex Bennée
2024-09-13 17:26 ` [PATCH 05/17] plugins: extend API to get latest memory value accessed Alex Bennée
2024-09-13 17:26 ` [PATCH 06/17] tests/tcg: add mechanism to run specific tests with plugins Alex Bennée
2024-09-13 17:26 ` [PATCH 07/17] tests/tcg: allow to check output of plugins Alex Bennée
2024-09-13 17:26 ` [PATCH 08/17] tests/tcg/plugins/mem: add option to print memory accesses Alex Bennée
2024-09-13 17:26 ` [PATCH 09/17] tests/tcg/multiarch: add test for plugin memory access Alex Bennée
2024-09-13 17:26 ` [PATCH 10/17] tests/tcg: clean up output of memory system test Alex Bennée
2024-09-13 17:26 ` [PATCH 11/17] tests/tcg: only read/write 64 bit words on 64 bit systems Alex Bennée
2024-09-13 20:15 ` Philippe Mathieu-Daudé
2024-09-16 8:41 ` Alex Bennée [this message]
2024-09-13 17:26 ` [PATCH 12/17] tests/tcg: ensure s390x-softmmu output redirected Alex Bennée
2024-09-16 5:27 ` Thomas Huth
2024-09-16 8:37 ` Alex Bennée
2024-09-13 17:26 ` [PATCH 13/17] tests/tcg: add a system test to check memory instrumentation Alex Bennée
2024-09-13 17:26 ` [PATCH 14/17] util/timer: avoid deadlock when shutting down Alex Bennée
2024-09-13 17:26 ` [PATCH 15/17] contrib/plugins: Add a plugin to generate basic block vectors Alex Bennée
2024-09-13 17:26 ` [PATCH 16/17] plugins: add plugin API to read guest memory Alex Bennée
2024-09-13 20:17 ` Philippe Mathieu-Daudé
2024-09-13 17:26 ` [PATCH 17/17] plugins: add option to dump write argument to syscall plugin Alex Bennée
2024-09-13 20:18 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xqwgfcx.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=danielhb413@gmail.com \
--cc=david@redhat.com \
--cc=devel@lists.libvirt.org \
--cc=eduardo@habkost.net \
--cc=erdnaxe@crans.org \
--cc=iii@linux.ibm.com \
--cc=ma.mandourr@gmail.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=npiggin@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
--cc=wangyanan55@huawei.com \
--cc=zhao1.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).