On Tue, 20 Jun 2023 at 16:38, Alex Bennée <alex.ben...@linaro.org> wrote: > > > Peter Maydell <peter.mayd...@linaro.org> writes: > > > On Tue, 20 Jun 2023 at 16:04, Alex Bennée <alex.ben...@linaro.org> wrote: > >> > >> We can return XKB_MOD_INVALID which rightly gets flagged by sanitisers > >> as an overly wide shift attempt. > >> > >> Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > >> --- > >> qemu-keymap.c | 24 ++++++++++++++++-------- > >> 1 file changed, 16 insertions(+), 8 deletions(-) > > > > Looking at the code that works with the mask values > > we are getting here, I think this ought to work > > (if there's no AltGr modifier then the 0 mask means > > the key state will be the same in normal and with the > > altgr mask supplied, which we already check for). > > Did you eyeball the output, though? > > > > Also, which keymap runs into this? Is it every keymap > > for some new version of the xkb data (which would imply > > that the problem is that the AltGr modifier has changed > > name), or is it only one specific keymap that happens > > to have no AltGr key? > > ar maybe? it only got flagged in clang-system once fedora was updated (I > assume with better sanitizers): > > [2773/3696] Generating pc-bios/keymaps/ar with a custom command > FAILED: pc-bios/keymaps/ar > /builds/stsquad/qemu/build/qemu-keymap -f pc-bios/keymaps/ar -l ar > ../qemu-keymap.c:223:16: runtime error: shift exponent 4294967295 is too > large for 32-bit type 'int' > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior > ../qemu-keymap.c:223:16 in > [2774/3696] Generating pc-bios/edk2-x86_64-code.fd with a custom command > (wrapped by meson to capture output) > [2775/3696] Generating pc-bios/edk2-x86_64-secure-code.fd with a custom > command (wrapped by meson to capture output) > ninja: build stopped: subcommand failed. > make: *** [Makefile:153: run-ninja] Error 1
OK; how does the output look from the new qemu-keymap on that system ? thanks -- PMM
