Register view ideas

[emoon]

Related twitter thread:

https://twitter.com/daniel_collin/status/753175420317626368

The idea here is to create a good register views because the ones that exists in most debuggers are pretty awful tbh. They pretty much only support hex and/or floats.

Some things were raised in the thread:

• If register points to a symbol (in memory) it should be shown
• Preview memory that register points to.
• Tree view style that allows folding/unfold to see more data

I started to prototype the last point a bit (notice that actual values aren't correct just dummy)

And this could work ok for SIMD up to certain size but may get harder if SIMD size is 128+ bites wide maybe it needs to be to split into more lines.

[hrydgard]

Ditch the commas, that saves a little space :)

Showing symbols is great, but viewing the data being pointed to seems more like something for a watch window, where you could do for example (to copy MSVC's syntax):

(uint32_t *)eax,100 

to view 100 dwords pointed to by eax. I miss that in most other debuggers I try (many of them have a way to do it but usually more complicated)

[emoon]

Yeah that syntax is pretty great for sure and something I will support support in watch for sure. And you may have a point. Maybe it's better to have memory preview in watch as preview here would make the UI more cluttered for sure.

[emoon]

I'm thinking symbol within paraphrases of register like this (if symbol is present, otherwise nothing like above)

rax 0xfadefade (_foobar)

[emoon]

@hrydgard Did some tests with dropping commas but it becomes hard to read it then and separate out where a specific value is. I tried something like this instead

[hrydgard]

Hey that's pretty nice, I really like the grouping.

[emoon]

Thanks. Yeah I think that can work good :)

Also thinking of how to deal with 256/512 bit registers

Instead of trying to cram everything "under one roof" maybe its better to do

+ zmm0 [0]
   ...
+ zmm0 [1]
   ...

Where each each of those [0], [1] is 128 bits

[hrydgard]

I suppose that depends on how wide the console is :) But that's certainly better than just blindly line wrapping, as it makes clean breaks at "even" positions in the superwide register.

[emoon]

Yeah but even if you have a wide console and line breaks it becomes hard after a while to know exactly what position you are on. What I'm saying that shouldn't need to sit and "count" to find the correct position of the specific part you are looking for.

While I like to have on register as one "unit" I think it would make sense to split even in the case of wide console for the reason above.

[hrydgard]

Yeah, true, though your '|' dividers make counting easier it's probably best to split anyway, at least at 512-bit...

[emoon]

Yeah that is what I'm thinking. I think I will start with that approach at least and see how it turns out. Regardless it seems that very few registers views has something similar to this anyway :)

[mrexodia]

We show symbols, labels,strings, (unicode) characters and module addresses (like ntdll.7680004D). That folding is a great idea but it might be nicer to show subregisters when you fold instead of other bases (and additionally provide options for base conversion in a menu or something).

[emoon]

What exactly do you mean by sub registers? do you mean rax, eax, al, ah for example?

[mrexodia]

Yeah that's what I meant.
On Wed, 27 Jul 2016 at 10:28, Daniel Collin [email protected]
wrote:

What exactly do you mean by sub registers? do you mean rax, eax, al, ah
for example?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#267 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACWCmXHXRhqJdB4fYHPP60q45JS1JkbLks5qZxbJgaJpZM4JVBG8
.

[emoon]

Yeah that works on x86/x64 but many CPUs doesn't have that concept (also SSE registers doesn't have that as well) Personally for me it would be useful to see in different bases as you may use SSE register as 16 8-bit values and not 4 - 32-bit values. It's possible to add more levels of folding but it shouldn't be "annoying" to find the right info but at the same time not display too much. Maybe

- xmm0 (0x2222 0x3333 ...)
    + [0] (0x2222)
    - [1] (0x3333)
         h8 (0 0 0 0 0)
         ...

[emoon]

More testing

vs

[emoon]

The idea with the first one is to reduce space when you unfold to the next level. Might be better to have it that way as one can pick the base one wants to look at mostly then but also requires some more fold/unfolding

[SlNPacifist]

What format should first line have? Something set by user? Should this format be global (for every register) or should it be set per register?

What happens with first line when register is expanded? Both variants above could just leave this string duplicated or do not render first line if register is expanded.

How should register be rendered if view width is not enough? Should it use horizontal scrolling or just wrap data to a new line? Or maybe it should have user picker for data width instead (like memory view has)?

How often are vertical bars rendered? Every fixed amount of bytes (images draw bars every 4 bytes) or something data-dependent?

[emoon]

First line should be decided by type of register, I would say integer registers should always be hex and vector/float should always be float but maybe it could be configurable for vector/float. Needs to be tested.

Like I wrote above maybe splitting larger registers (above 128 bits) into

+ zmm0 [0]
   ...
+ zmm0 [1]
   ...

I think many of the ideas above is just that ideas, it needs to be tested to see what makes sense.