> On 3 Mar 2026, at 14:09, Jan Beulich <[email protected]> wrote: > > On 03.03.2026 15:07, Jan Beulich wrote: >> On 27.02.2026 11:58, Edwin Török wrote: >>> --- a/tools/tests/x86_emulator/test_x86_emulator.c >>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c >>> @@ -1100,7 +1100,7 @@ int main(int argc, char **argv) >>> regs.edi = (unsigned long)res; >>> rc = x86_emulate(&ctxt, &emulops); >>> if ( (rc != X86EMUL_OKAY) || >>> - (*res != ((0x2233445F << 2) | 2)) || >>> + (*res != ((0x2233445FUL << 2) | 2)) || >> >> Why the L when res is an array of unsigned int? With it dropped (happy >> to do so while committing): >> Acked-by: Jan Beulich <[email protected]> > > I should probably add that nevertheless it's not quite clear to me what use it > is to compile the harness source itself with sanitizer options.
I was trying to see why the tests were failing with clang, but not GCC. That could also be because clang takes different (optimisation) decisions on how to handle undefined behaviour. It turned out that undefined behaviour wasn’t the reason the results were different, but I sent some patches to fix some of the (currently latent) bugs it uncovered. > I can see that > to be useful for the core emulator files compiled into the harness binary. > For sanitisers like the memory sanitisers (which detects reads from uninitialized values) I think it is best to have the whole program compiled with it (the uninitialised value could originate in a different file). Or at least as far as reasonable (I’m not rebuilding libc). But even for the address sanitiser a buffer could be allocated (e.g. on the stack) in a different file than where the bug is. Best regards, —Edwin
