Update to QEMU v9.0.0

[rmalmain]

Also, replaced VLAs in vector instructions by dynamic arrays.

[aurelf]

The test error comes from the fact that printf tests only generate 4 test cases, while orginally there were 27 more.

[...]
#17 3.793 AssertionError: Lists differ: ['000008', '000018', '000021', '000022', '[476 chars]tic'] != []
#17 3.793 
#17 3.793 First list contains 27 additional elements.
[... ]

This actually highlights a significant regression, it would be nice to understand the root cause?

[aurelf]

So using bisect is infeasible, because we end up on the main QEMU branch without SymQEMU changes, and merging SymQEMU at each bisect point is painful. I instead merged little by little and it seems that the offending changes are in between these two points in the main qemu branch: d328fef93ae757a0dd65ed786a4086e27952eef3..c8193acc078e297fd46b6229e02b819b65c6702e This is 77 commits. We need to refine further to find the origin of the issue, but some change tcg there are seem good candidates.

[aurelf]

Hum, after some scripting, it seems that the issue appears first with 24c0573bb0c3f55c47926e3cb047a716608cd113 We need to make this SymQEMU compatible.

[rmalmain]

Thanks a lot for the debugging work. I'll have a look today

[aurelf]

Remaining differences are due to this commit d4f611711a9abe23616d6d965fba955340d11d0d

[rmalmain]

It should be ready @aurelf, I squashed everything in the merge commit. I'll commit the rest whenever we merge into master. Is it fine like this?

[aurelf]

Thanks ! I see a few problems: The merge commit patch includes many things, but zero comment :/ Each change should be documented in the commit message, I see at least :

• no vla,
• fix for the regression introduced in https://github.com/eurecom-s3/symqemu/commit/24c0573bb0c3f55c47926e3cb047a716608cd113 and that changes in test cases from https://github.com/eurecom-s3/symqemu/commit/d4f611711a9abe23616d6d965fba955340d11d0d were "accepted" as they seem to be due to
• path update
• tests/symqemu/util.py changes should be in a different commit ? I honestly wonder if it would not be better to have the merge alone, then the fixes as different commits, changes in merge commits are difficult to see, diff does not work well (diff to one or the other parent are large), and git show only shows an approximation of a patch with 2 ancestors, which is a mess (and github doesn't seem to do this, or it's not obvious :) ). That would mean having a few commits that don't work in the history, which I think is better than an obscure blob merging 2 histories and some fixes... If anything there introduces a problem it will be hard to test, documenting the changes is problematic... What do you think ?

[aurelf]

Thinking about it we can keep the one merge commit and changes, this is also what we did for previous merges. But we need to have a detailed merge commit message that explain all the changes needed for the merge. Can you amend the last commit for this? Also don't mention update_9_0_0 branch name, this is only local.