Add a scrollbar to the disassembly window

[Anohkka]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository
• I made sure to follow the project's coding style
• I've updated the documentation with the relevant information (if needed)

Detailed description

Implements a scroll bar for the disassembly window. Helps with viewing different sections of a file in multiple disassembly windows, and is useful for scrolling through the binary during a debug session.

Test plan (required)

Tested with multiple, different binaries:

• Verified that scroll bar stays synchronized with the visual nav bar while seeking through the visual nav bar.
• Verified that multiple disassembler windows have separate scroll bars.
  • Seeking on one disassembler window will move every disassembler window to the selected address. This is the current behavior and has been left as is.
• Verified that scrolling with the scroll bar and Page Up / Page Down are both unchanged - they do not snap to the scroll bar's range.
• Verified that the scroll bar's range correctly maps to the binary in memory while debugging.
• Verified that the scroll bar's range correctly maps to the binary while emulating it.

Things I could not test:

• Loading a file without bin information, since that option is broken on my system (see Do not load bin information option is broken #3249).
• Remote debugging, also broken on my system, even though it works fine on Rizin. The way I implemented the scroll bar range should work fine for remote debugging as well though.

Closing issues

Closes #2907.

[karliss]

This needs a lot more serious testing and a test plan across various usecases supported by cutter/rizin as mentioned in the mattermost discussion.

[karliss]

Just playing with it for 10minutes made it break in so many different ways there is no point in me listing them or doing further review until you come up with more serious test plan and go through with it fixing any problems you find during the process.

Try actually using the Cutter (with the new scrollbar) and not just opening single unspecified file and doing 5 seconds of scrolling without paying attention what you are looking at beyond the fact that it changes somehow as you scroll. Try actually reading the disassembly while using the scrollbar. If you have no reverse engineering experience or understanding about various executable formats, feel free to spend a week trying to learn basics first and then return to this PR, otherwise it will be very hard for you to evaluate whether stuff you see makes any sense.

[wargio]

it's ok karliss. it's not a simple issue. they are trying to fix some issues to get used to the code.

[Anohkka]

Karliss, first of all, thank you for taking the time to test my PR.

I'm aware of my limitations when it comes to testing PRs here - I'm not a reverse engineer, and even a week using Cutter would not be enough to find every edge case. I had assumed that tying the scroll bar to the disassembly window refresh function would be enough, but it clearly was not.

It would be very helpful if you listed all the ways you made the scroll bar break, but I understand your frustration. I will spend more time with Cutter, prodding around for bugs in the scroll bar, in order to iron out the remaining kinks in its implementation.

[karliss]

Looking more promising already.

Compared to initiatial version doesn't crash when opening small files anymore, works better when debugging, doesn't use completely nonsensical range when opening PE(.exe) executables.

There seems to be some bug with handling end of range. Here are the steps I did:

1. copy and paste 0x00008a0b copies of "90" in open shellcode tab and open it, exact count probably doesn't matter but it should be on the same order of magnitude
2. reduce the height of disassembly window as much as possible
3. attempt scrolling to the bottom using scrollbar

Expected result:
Instruction at 0x00008a0b is either somewhere in screen or one instruction above the first visible instruction. (Not asking for it to be perfectly at bottom, as that's currently not easily possible due to line!=byte) .

Actual result:
last visible instruction is at 0x89ef, cutting off some of the last instructions.

Another problem I observed is where you can't reach use scrollbar to reach the top under certain conditions. Something like:

1. Jump to the middle of executable
2. jump to an address 20 bytes after the scrollbar top using "Type flag name or address here".
3. try to drag the scrollbar up to reach the actual top -> position doesn't change

I am guessing that both problems are actually caused by bad edge case handling in with the max 100 and currentVScrollAddr() logic. Once you bump the max value as requested in other comment, it might look like the problem disasppeared. But it will likely still be there, just harder to trigger. So I recommend fixing these 2 first and only then dealing with raising max scroll value.

[Anohkka]

Both issues should be fixed. Let me know if there's anything else that needs work.

[karliss]

Don't forget to fix CI failures.

There is something very weird happening near the end.

Open shellcode with 0x00000168 bytes an slowly drag the scrollbar to bottom. Near the end it suddenly jumps to the end, but keeps reacting mouse movement.

Probably related, if you slowly scroll with a scrollwheel of such file (tested with 0x87), there is point near end where scrolling by 3 lines suddenly cause scrollbar position to jump by a lot. I am guessing some kind of inconsistency in scrolbar->address, adress->scrollbar mapping in combination with callback loop (scrollbar updates seek position, seek position updates scrollbar pos).

Problem is even more exaggerated if you open raw binary file (64 bytes) and in advanced options during opening set map offset to 0x1000 (it's equally bad for the same file without setting map offset)

With small files for example 43, there is a different 2 byte jump near the end. As you scroll with scrollbar, the top position changes 0x24, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2b. , skipping 0x2a. Not sure if it's related or separate problem from the one described above.

[Anohkka]

Addressed those issues as well. Scrolling to the bottom now should place the binary's end offset at the top of the disassembly viewer. Not ideal, but it's hard to do better. The only other option I see is to perform a binary search using CutterCore::disassembleLines with different offsets until we find an offset where the binary's end offset is at the last line.

[karliss]

Addressed those issues as well. Scrolling to the bottom now should place the binary's end offset at the top of the disassembly viewer. Not ideal, but it's hard to do better.

Like i said in #3430 (review) that's acceptable. I have some plans for improving line handling in disassembly widget but that's a separate giant task.

[karliss]

Moving down using little arrows at bottom and top of scrollbar doesn't work in a ~200KB file. Moving up works fine.

Make sure to have chosen system qt theme which doesn't hide them, for example Fusion and Windows.

[Anohkka]

The scroll bar buttons work even if you're viewing something outside the scroll bar's range. They behave somewhat weirdly in that if you're past the end of the scroll bar's range and try to scroll up, it works fine, but scrolling down won't work. How should the scroll bar behave in such cases? Some options:

• Snapping back into the scroll bar address range if you press a scroll bar button

• Allowing the scroll bar buttons to scroll beyond the binary address range

  • Always? Only when debugging? Only when you're already viewing an address outside the scroll bar's range?

• Preventing use of the scroll bar buttons altogether while outside the scroll bar address range

• Keeping them as is

[karliss]

I don't have any strong feeling with regards to button behavior outside the range, except that they shouldn't cause snapping behavior.

Working always (2.1) or as is towards range (4) would be fine with me.