New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ZMM registers - visualizing #1977

Open
greenozon opened this Issue Jun 30, 2018 · 9 comments

Comments

Projects
None yet
2 participants
@greenozon

greenozon commented Jun 30, 2018

  • Debugger version (can be found on right hand side of menu bar of debugger).
    Jun 19, 2018

  • Operating system version and Service Pack (including 32 or 64 bits).
    Win10

  • Brief description of the issue.
    ZMM/AVX512 are supported, great news!
    but there are no ZMMxx registers printed on the registers pane (or I missed steps to make it visible?)

zmm

Similar ideas/refs:
#304
#701

PS
I guess in mid 2018 its a good time to have full support of this great new tech
MS VS 2017 supports it! https://blogs.msdn.microsoft.com/vcblog/2017/07/11/microsoft-visual-studio-2017-supports-intel-avx-512/

GCC/clang/icc/etc supports it!
There are already many Intel CPU having it inside! :)

thank you

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jun 30, 2018

Last time I checked there was no API to retrieve those registers. Do you know which API to use?

@greenozon

This comment has been minimized.

greenozon commented Jun 30, 2018

do you mean smth like was done for xmm/ymm? (wow, it'll never be available for win7...)

https://docs.microsoft.com/en-us/windows/desktop/Debug/working-with-xstate-context

meanwhile, what is the current way (in code of debugger) to get the values for xmm/ymm when debugging?

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jun 30, 2018

Currently this xstate is used, but there is no mention in the documentation about avx-512

@greenozon

This comment has been minimized.

greenozon commented Jun 30, 2018

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jun 30, 2018

@greenozon

This comment has been minimized.

greenozon commented Jun 30, 2018

I've one more idea - if you don't mind
how about the debugger will scan CPU that it's running on (using cpuid command I guess) and in case there is no avx/avx512 support - debugger will hide showing ymm/zmm registers (as they are quite long in size!)
what you say?

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jun 30, 2018

@mrexodia mrexodia added the feature label Jul 1, 2018

@greenozon

This comment has been minimized.

greenozon commented Aug 12, 2018

@mrexodia I"d like to push this issue forward and I've some questions to you.
As far as I see x64dbg uses TitanEngine module to communicate with/control/etc the CPU, one of the comm flow is to get/set registers. Now I"m a bit stucked as I did not find TitanEngine sources in your repository, just compiled bits. Ideally it'd be present here as a git submodule, or, 2nd option - as a separate dir with full sources.
In my understanding I need to extend context structures from both sides - the debugger (REGISTERCONTEXT) and titan engine (TITAN_ENGINE_CONTEXT_t) + corresponding APIs (eg: GetFullContextDataEx(), SetFullContextDataEx(), etc)
I envision there need to be added a set of new APIs to handle AVX512/ZMM (analogy as it was done right now for Get/SetAVXContext(), right?)

Please let me know how could one start updating TitaneEngine side.
The debugger side is clear for me.

@mrexodia

This comment has been minimized.

Member

mrexodia commented Aug 12, 2018

@greenozon You can find the sources of TitanEngine at https://bitbucket.org/titanengineupdate/titanengine-update/branch/x64dbg. They are not directly part of the x64dbg repository because it uses Visual Studio 2010 to compile and I don't want to have that as a requirement. The idea for a very long time now has been to replace TitanEngine with GleeBug, but there are some blocking issues there that nobody has resolved so far.

It will require some additional effort to preserve backwards-compatibility in DbgGetRegDumpEx, but apart from that I don't think there will be many issues (just that you have to copy pasta the new headers and make sure everything stays compatible with Windows XP/Visual Studio 2010).

One thing that might be possible is to replace TitanEngine with a minimal version of TitanEngine that allows x64dbg to work. This would likely increase performance and it would be no problem to include that code directly in x64dbg.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment