@mrexodia I need your suggestions on API changes and compatibility. Currently managing AVX-512 register contexts uses all new APIs in TitanEngine, x32dbg, and x32bridge. There will also be breaking changes to trace files (#3136).

When Intel “AVX-10” comes out with new registers R16-R31, YMM16-YMM31 and XMM16-XMM31 breaking changes will again be required. Therefore it seems better to create different REGDUMP structures for different compatibility and needs (#3116, #3136 and AVX-10) and use a new API interface like bool DbgGetRegDumpEx(REGDUMP* regdump, size_t size);

Yeah I agree with doing DbgGetRegDumpEx. Honestly I thought we were already kinda doing that. The _dbg_xxx APIs do not need to be backwards compatible, so we can just introduce a new size parameter there perhaps?

Also are you good with moving to Visual Studio 2022 and Qt6? I think for a while we will keep support for Qt 5.6 and VS2013 for a while, but eventually move to modern standards. Doing two snapshots will break all Qt plugins, but I think it's really time. The CMake changes should make this pretty transparent, we just have to keep writing C++11 for now if we want XP compatibility.

What do you think of API interface in TitanEngine (and you will need to copy that code into GleeBug)?

I'm already using Visual Studio 2022, just not Qt 6 yet. I don't want to have a Qt account.

What do you think of API interface in TitanEngine (and you will need to copy that code into GleeBug)?

Yeah it looks good, nothing controversial in there I think! I will fix the CI and merge it as well as port the changes to GleeBug.

I'm already using Visual Studio 2022, just not Qt 6 yet. I don't want to have a Qt account.

I will make sure to publish the extracted Qt installations as 7z archives on GitHub and SourceForge. Any other place I should publish it to make them easy to download?

There will also be breaking changes to trace files

I think while we're at it, there was some issue with an 8-bit index being used for memory sizes and this was causing some overflow with instructions like FXSAVE: https://pvs-studio.com/en/blog/posts/cpp/1146/#ID906A1478C3. We have a mechanism to version the trace files afaik, so that should also be a safe addition.

This weekend I will try to move x64dbg to a more modern stack, let's pray Microsoft won't decide to break ABI compatibility with their next Visual Studio release and then we should be set for the foreseeable future.

CI won’t work until changes in TitanEngine are merged. Currently GetThreadContext is called multiple times in TitanEngine, for general purpose registers, for AVX and for AVX-512 separately. In fact it should be called only once, that still needs to be fixed. So I’m also going to add a DbgGetRegDumpEx-like API interface in TitanEngine.

Edit: I just canceled this plan, decided not to change current TitanEngine API. Not many places need AVX-512, so don’t need to update everywhere just to get everything together with AVX-512 registers.

Yeah my plan is to merge the TitanEngine/GleeBug changes and then add them as submodules to the x64dbg repo directory. This way we do not have to keep shipping binaries for updates like this...

Note: when testing AVX-512 register modification, remember #693. The program has to use AVX-512 registers once before they can be modified. I’ll see whether it can be fixed in TitanEngine.

Now it's possible to view ZMM registers in the RegistersView!
Because there are so many XMM, YMM and ZMM registers, these registers are now combined. If it has a nonzero value in the AVX512 part, then only ZMM registers are shown, otherwise if it has a nonzero value in the AVX part, then only YMM registers are shown, otherwise, just XMM registers are shown.

Now it's mostly complete except tracing support, which will be worked on later. I hope we will get it ready soon with a news update!

I updated the TitanEngine.dll files for all debug engine. At a later date I will start including them in the CMake project.