Skip to content
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

Make enum for psuedo registers #42

Closed
Zhentar opened this issue Oct 22, 2018 · 4 comments
Closed

Make enum for psuedo registers #42

Zhentar opened this issue Oct 22, 2018 · 4 comments

Comments

@Zhentar
Copy link
Contributor

Zhentar commented Oct 22, 2018

Save my conscience from the magic string!
DbgPseudoRegisterInfo.GetDbgPsedoRegisterInfo(Debugger, "$peb").Value

@jazzdelightsme
Copy link
Member

Thank you for the feedback!

I'm curious about your scenario: you are using DbgShell from C#? (I tried to write DbgProvider.dll with the idea that one might want to do that, but I haven't really ever done it save from within DbgShell itself)

In this case, that function is pretty much a straight pass-through to dbgeng. I could scrape through IDebugRegisters.GetPseudoIndexByNameWide and then make an Enum based on the list of names I got, but I believe the set of names may be different for each target platform. We could just include all the names in the enum, and you're just out of luck if you ask for a name that doesn't exist for your target. But since you have to have special understanding of your target platform to use such an Enum correctly, I don't think it's much improvement over using a magic string. In fact, requiring one to use a special string helps emphasize this. So I'm not convinced this is really worth doing. What do you think?

And you could also write your own wrapper function with your own enum.

@Zhentar
Copy link
Contributor Author

Zhentar commented Oct 24, 2018

If you mean as a standalone application, I am but basically just as a prototyping aid. But I am prototyping C# Cmdlets, so similar to what DbgShell itself does.

My main objection to the magic strings is that they lack discoverability - you have to be familiar with DbgEng supports to consume them at all. A secondary concern is that they have been chosen favoring brevity over clarity; .ProcessEnvironmentBlock is going to be much easier for one of my coworkers less familiar with this to understand than $peb.

However, after thinking on your target platform comment, I realized that $peb and $teb are quite a bit different from the other registers in that DbgShell requires ntdll symbols to handle them. Maybe it would be better to have GetDbgPsuedoRegisterInfo return just the addresses for them and offer a different option to get the full typed objects?

@jazzdelightsme
Copy link
Member

Maybe it would be better to have GetDbgPsuedoRegisterInfo return just the addresses for them and offer a different option to get the full typed objects?

The raw info is available in the DEBUG_VALUE property... Another option is to just expose GetValueFromRawValue() (it's currently marked protected) (and maybe rename it). There is also a ValueAsPointer property... but I believe it is broken for strongly-typed pseudo registers. :/

@Zhentar
Copy link
Contributor Author

Zhentar commented Jan 22, 2019

As per my pull request, it has to be the "offer a different option" route - $peb and $teb do not do what I need because they always return the 64-bit peb/teb for WoW64 dumps, and I need the 32-bit peb.

@Zhentar Zhentar closed this as completed Jan 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants