So, I think you're going to know what I'm going to ask. Tests 😄 ?

lol. sure. do we have a pattern already setup for symboliks testing?

Yup! See test_translator.py and the associated data_i386.py and data_amd64.py in vivisect/symboliks/tests`

So there is some stuff in the manual about modding the shift value by the bitsize (which we handle in the other i386 envi emulator, but not the amd64 emulator, which we need to fix). We follow something simillar for rol in the symboliks emulator. Think it's worth it to do here as well?

hmmmm.... yes. we should. we should discuss how masking is done and consider better ways.

question: how's the opcode storing 64-bit mode? is it an iflag, or do i have to manually check the prefixes and look for the magic combinations?

I believe I usually use the getWidth() method or just reach into the full op object and grab the tsize value.

Kinda feels like we might want an additional check box for these (or just keep it showing only under alleff. Because DebugEffect doesn't actually affect emulator state, so it'd be more confusing to see these here. I'd prefer to keep the split of what shows by default in symboliks to be "Here are the things we know to have big effects on the symbolik state", and then let the all effects checkbox show everything else. It keeps things tidy and focused in the default view.

Side note: we should just carve the effect.walkTree..... block into a subfunction. The copypasta here is silly.

i completely disagree on this one. this whole tool is a visual communicator of symbolik state.

DebugEffect doesn't affect emulator state, but the instruction that isn't defined likely would have.... thus, the existence of DebugEffect should not be hidden from the user without risking their loss of trust. i've had this happen very recently. only because i worked through the details and something didn't look right did I think to enable alleff.

My problem is that is overloads It is a communicator of symbolik state, but there's several we don't display. I still err on the side of not displaying too much, and until the full set of instructions is covered, we're going to have these, and for the most part, they really just clutter the space up. Displaying too much data is just as bad as displaying not enough, because it will cause eyes to glaze over. So I'm not convinced we're losing any kind of trust here when you can just click a box to see them. At worst we can add another to show the debug effects. But I'm against shoving a mountain of text in front of the user when the option to show it is right there.

i don't run into too many. but when i do, i have to know, there's not "I don't want to know that may symbolik state is completely fucked." ever.

i'm with you on overload. the magic is getting just the right information displayed.

i cannot be convinced at this point (having used Symboliks for 10+ years) that these are not important, ever. if nothing else, we need to tag the top of the symbolik view with "some instructions were not supported so this state is erroneous. check "all effects" to see the details."

but this is easier and better in my opinion.

I'm not saying they're not important. I'm saying that I don't want them displayed by default. I've also used symboliks for several years, and when using the symboliks view, for any function beyond very simple functions, the amount of text/info in there tends to be a lot, and it's extraordinarily non-trivial to parse and link that info back to the assembly. Flat out displaying more by default doesn't help that. Displaying a mountain of data with no way to filter or sort down is not a pleasant user experience. It's a big reason why I tend not to use the UI version of symboliks and just drop into a shell. Filtering is important.

So while displaying this by default always is easier, I disagree that it's better. At least with it in alleffs, there is a very rudimentary way to filter the symboilk state. I'd be fine with a checkbox at the top along the lines of "Unsupported Instrutions Detected. Display Effects?" that can be used to explicitly tell the user that the symbolik state may be missing elements. Even better might be a drop down filter list of the effects in the currently selected path (along with how many of those effects are in the path), and maybe a warning in the topbar of the symboliks pane if there are DebugEffects detected. But I don't want the DebugEffects always showing in the view without some way to filter them out.

question: how many instructions do you expect to be not supported?
how many should stay that way?

these are gaps that (1) shouldn't be there, and (2) typically dramatically affect the accuracy of SymboliksView.
displaying them adds discrete lines. they don't show up in the crazy symbolik state lines. if anything, they'll be easy on the eyes.

oh, and we're more likely to implement/fix them if they're a little annoying to everyone.

shld also has the portion about 1 bit shifts affect the overflow flag that we should add. (and technically a blurb about if the count is greater than the operand size, the flags being undefined)

i'm open to suggestions on how to implement this. but it's causing me issues at this very moment. thus the implementation PR.

so... it seems like we need to have some if/then/else capability for the flags. or some sort of constraint. we often can't know until symbolik-emulation time what CL is going to be... so how do we best assert our will here?

Hmm. Yea. We might want to discuss a new SymbolikEffect that collapses/calls a callback on apply/reduce. That might solve some of our branching logic states maybe?