CPU-View

[Fibonacci]

I forked your repos and changed 2 things:

1. Go backward on VK_BACK, not VK_ESCAPE
2. VK_ESCAPE hides the window

[Alexander (Rouse_) Bagel]

I forked your repos and changed 2 things:

1. Go backward on VK_BACK, not VK_ESCAPE
2. VK_ESCAPE hides the window

I think this needs to be tucked away in the settings, I'll add hotkeys a little later.

UPD: I've made some preliminary preparations to customize the ShortCuts
https://github.com/AlexanderBagel/FWHexView/commit/83928992189771199c6fe5d20a6a824d3e5beb79

And also added for the new Secondary ShortCut to handle the stack of jumps (Num+/Num-)
https://github.com/AlexanderBagel/CPUView/commit/1abc496a20c86d94911a47ca08479d280f1c32da

[Alexander (Rouse_) Bagel]

I forked your repos and changed 2 things:

1. Go backward on VK_BACK, not VK_ESCAPE
2. VK_ESCAPE hides the window

I considered this mode of operation and it seemed in principle quite convenient.
I made changes in the code, now VK_ESCAPE closes the dialog, jump control buttons VK_RETURN/VK_BACKSPACE, Num+/Num- or mouse buttons MK_XBUTTON1/MK_XBUTTON2.
It is necessary to reinstall both packages.

[Alexander (Rouse_) Bagel]

Well, I will suspend CPU-View development for the New Year holidays.
A lot of changes have been implemented over the last couple of months.
Of the most important ones:
Deep debug information search. This mode analyzes the entire address chain in search of a debugging symbol.
Address validation - a mechanism that searches for information about each displayed address
Active highlighting and hints to validated addresses (I've been working on the organization of hints for a long time).
A lot of other things I can't remember already

Don't forget to reinstall FWHexView first when updating CPU-View: https://github.com/AlexanderBagel/FWHexView

And also CPU-View itself
https://github.com/AlexanderBagel/CPUView

[Alexander (Rouse_) Bagel]

As of January 17, 2025, daily CPU-View updates have been suspended. 

All core functionality has been added, only 4 steps remain, each of which will require a long development time and will not be posted so as not to break the current CPU-View behavior. 

1. SIMD register editor.
2. Window displaying function call parameters.
3. Carbon/Cocoa widget support under macOS.
4. Support for ARM architecture.

Don't forget to reinstall FWHexView first when updating CPU-View: https://github.com/AlexanderBagel/FWHexView

And also CPU-View itself
https://github.com/AlexanderBagel/CPUView

[Alexander (Rouse_) Bagel]

A small update in CPU-View. To be more precise, there were a dozen of them with bug fixes, but the current one already extends the functionality.
So the general concept:
In the process of debugging can often happen a situation with a failure of the debug stack, this is due to many reasons, usually playing with stack registers RBP/RSP.
When the stack is broken, it is not clear where the call came from and it causes great difficulties when debugging such code.
In such a situation, the “Step Out” command will be executed incorrectly and with 99% probability will simply start the process for execution instead of stopping at the address of the current procedure call.
Some time ago I added a “Run to User Code” mechanism that relies mostly on information from the debugger, and if it didn't contain the necessary data, the stack frames were analyzed.
This approach works quite well on Windows, but unfortunately it doesn't work on Linux anymore. Gtk libraries are built without using stack frames and stack promotion via RBP/RSP does not give the necessary result.
Having experimented with several variants of solving the problem, I found one that works quite accurately, the essence of which is to analyze the entire stack below the RSP and group setting temporary Breakpoints by a list of all possible return addresses.
Experimental results on the video: https://raw.githubusercontent.com/AlexanderBagel/CPUView/main/img/run_to_user_code.mp4

The code is available on GitHub: https://github.com/AlexanderBagel/CPUView
Don't forget to reinstall FWHexView first when updating CPU-View: https://github.com/AlexanderBagel/FWHexView

[Martin_fr]

In the process of debugging can often happen a situation with a failure of the debug stack, this is due to many reasons, usually playing with stack registers RBP/RSP.
When the stack is broken, it is not clear where the call came from and it causes great difficulties when debugging such code.
In such a situation, the “Step Out” command will be executed incorrectly and with 99% probability will simply start the process for execution instead of stopping at the address of the current procedure call.

I have to double check, but I think the "Step out" is not currently even using the same "smarts" as the callstack.

Originally, both just had the "RSP" (which already becomes tricky, when the code is asm stepping through the "leave" part of the procedure.

Also the RSP has a habit of skipping frames, when you have an optimized fpc RTL  (or your own code) with omitted frames (some functions not setting the RSP). Then those functions will be visible, but their caller will be hidden. (Hence the RTL can hide routines from the users code in the stack).

The stack then was improved.
- The stack now can use dwarf to find its parent
- The stack can actually disassemble the machine code, and often find exactly where the code would return, and what would be popped of the stack before.

Of course the disassembling is limited. It only has a known subset of asm that it "interprets". But it manages most of the Window and Linux kernel and system libs (well in my tests, that is)

But the "Step out" has not yet been updated. So even in cases where the stack shows this, the step out may not use it and fail. That is another todo.

----
As for the stack, in cases nothing can be found, your idea is a good last resort. I have seen gdb doing something like that: any code address was shown as a stackframe. So there were many extra/wrong frames. But the correct ones where in there too.

[Martin_fr]

Which Lazarus version was the video made with? I wonder, because I have gotten stacktraces in the gtk libs, going over more than 20 frames down to the LCL code.

[Alexander (Rouse_) Bagel]

Which Lazarus version was the video made with? I wonder, because I have gotten stacktraces in the gtk libs, going over more than 20 frames down to the LCL code.

Lazarus 4.99 (rev main_4_99-1103-g6c528d9822) FPC 3.3.1 x86_64-linux-gtk2

[Alexander (Rouse_) Bagel]

As for the stack, in cases nothing can be found, your idea is a good last resort. I have seen gdb doing something like that: any code address was shown as a stackframe. So there were many extra/wrong frames. But the correct ones where in there too.

At first I used to exit to the lost stack by manually passing through Jxx (via F4) + RET, then I tried to automate it and it even worked, but slowly, because this option implies a multiple cycle of starting/stopping the process at the calculated address through disassembling.
In the end I gave up this approach, because the debugger has a really powerful mechanism for setting multiple temporary breakpoints, it was just perfect for solving this problem for O(N) since I have all the data available, I just needed to collect them in one array.

[Martin_fr]

Well, ... about multiple breakpoints.

There is a tiny danger in it. (One that actually has happened with gdb, because older FPC wrote incorrect info).

If you have a breakpoint at the wrong address, then the app may crash.
- Imagine you have an asm statement at 0x223308. that statement is 3 bytes long.
- On the stack you find the address 0x223309
- Now you may check that the asm at this address is a "call" statement, but the 2nd byte of that real statement may just be a "call".

So you are setting a breakpoint in the middle of a statement. If the code then reaches that statement, it does not see a breakpoint, but instead executes a modified statement. That is most likely to cause trouble.

[Martin_fr]

As for using disassembly for calculation. Yes that is slower.

Well, if you just want to display a stack in the stack window, then you need the info without execution anyway. So for display of a stack it still is a good way.

Of course displaying all potential frames also works, and then the user can select. But if the user selects wrong, and a breakpoint gets set then the problem is back.


The disassembly resolver is in FpDbgCpuX86

Maybe we can figure out why it stops early in some of the stacktraces you have. If it can be improved that would be good.

Also maybe it can be compared with your approach? (I understand you wrote your own decoder for that purpose?).

I have to go looking through my "old bits of code". I should somewhere have some debug patch for that code, which will output info, for what it tries, and where it fails.

[Martin_fr]

My bad, the dissas-stack-tracer is in FpDbgDisasX86.

Code: Pascal  [Select][+][-]

1. function TX86AsmDecoder.UnwindFrame(

First thing you can try is to increase the following values

Code: Pascal  [Select][+][-]

1. const
2.   MAX_SEARCH_ADDR = 8000;
3.   MAX_SEARCH_CNT = 400;
4.   MAX_ADDR_DONE_BLOCKS = 10;
5.   MAX_FORWARD_ADDR = 5;
6.  

Just multiply them all by 10.
And see if that gets any improvement.

[Alexander (Rouse_) Bagel]

First thing you can try is to increase the following values

Code: Pascal  [Select][+][-]

1. const
2.   MAX_SEARCH_ADDR = 8000;
3.   MAX_SEARCH_CNT = 400;
4.   MAX_ADDR_DONE_BLOCKS = 10;
5.   MAX_FORWARD_ADDR = 5;
6.  

Just multiply them all by 10.
And see if that gets any improvement.

Got it, I'll check those parameters as well.

UPD: this has no effect on the current build, I will check it later on the latest trunk.

[Martin_fr]

UPD: this has no effect on the current build, I will check it later on the latest trunk.

The latest changes were in Oct 2024. So if you have that, then you are up to date.


I did have a look though and saw that I did not fully implement all variants of "push/pop". Mainly pushf / pusha and popf / popa.
I just never encountered them, and didn't spent time looking up what exactly they do.

So if your libs have them, then that may be a reason.