Enhance debugger status bar with function and address information using stack trace symbolization

[Copilot]

The debugger status bar now displays comprehensive information when the target has stopped, showing the current address with function symbolization that uses the exact same approach as the stack trace widget.

Changes Made

Enhanced the TargetStoppedEventType case in DebuggerStatusBarWidget::updateStatusText() to include:

• Current instruction pointer address - Shows where execution stopped with 0x prefix
• Stack trace widget symbolization - Uses identical approach as stack trace for function information
• Function information from frames - Displays function names and offsets from actual frame data (e.g., "main + 0x34")
• Module fallback - Shows module name and offset when frame/function info is unavailable
• Unknown module handling - Uses "??" when no information can be determined

Symbolization Approach

The status bar now uses the exact same symbolization method as the stack trace widget:

1. Get current thread frames - Retrieves stack frames for the active thread
2. Use first frame data - Extracts function information from current execution frame
3. Apply stack trace formatting - Uses identical logic as FrameItem constructor
4. Handle WinDbg format - Removes module! prefix from function names
5. Calculate precise offset - Uses frame.m_pc - frame.m_functionStart
6. Fallback to module+offset - When no frame/function data is available

Example Output

Before:

Stopped (breakpoint)

After (when function info available from frames):

Stopped (breakpoint) at 0x401234 (main + 0x34)
Stopped (single step) at 0x7fff12345678 (printf)
Stopped (breakpoint) at 0x401200 (main)

After (fallback to module info):

Stopped (breakpoint) at 0x401234 (helloworld.exe + 0x1234)
Stopped (breakpoint) at 0x401234 (?? + 0x401234)

Implementation Details

• Uses GetFramesOfThread() to retrieve actual frame data from the debugger
• Extracts function information from the first frame (current execution context)
• Applies the same formatting logic as the stack trace widget's FrameItem constructor
• Handles WinDbg module!function format by removing module prefix
• Calculates offset using frame.m_pc - frame.m_functionStart for precision
• Falls back to AbsoluteAddressToRelative() when frame data is unavailable
• Extracts filename from full module paths for cleaner display
• Handles both Windows (\) and Unix (/) path separators
• Increased status bar buffer from 50 to 100 characters to accommodate longer messages
• Added null safety checks for debugger instance
• Maintains backward compatibility - other status messages remain unchanged

The enhancement provides precise debugging context by using the exact same function symbolization as the stack trace widget. This ensures perfect consistency with existing UI and eliminates irrelevant string analysis, providing immediate context about where execution stopped using actual frame data from the debugger.

Fixes #841.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[xusheng6]

@copilot when it is possible, prefer to display the IP as function + offset. Only fallback to module+offset when it is not possible. Check how the stack trace is displayed and symbolized

[Copilot]

@copilot when it is possible, prefer to display the IP as function + offset. Only fallback to module+offset when it is not possible. Check how the stack trace is displayed and symbolized

Updated the implementation to prioritize function+offset over module+offset, matching the stack trace behavior. Now uses GetAddressInformation() first to get function/symbol information, with module+offset as fallback when function info is unavailable.

New priority order:

1. Function + offset (e.g., "main + 0x34")
2. Function symbols (e.g., "printf")
3. Data variables (e.g., "data_401200 + 0x8")
4. Module + offset fallback (e.g., "helloworld.exe + 0x1234")

Example outputs:

• Stopped (breakpoint) at 0x401234 (main + 0x34) ← When function info available
• Stopped (breakpoint) at 0x401234 (helloworld.exe + 0x1234) ← Fallback to module

Commit: b41ac95

[xusheng6]

@copilot, no, GetAddressInformation would not do it. That API also checks the address for strings at the address, which is not relevant for this purpose. The symbolization of the address should be the same as the one shown in the stack trace widget, retrieve that and see how the stack trace widget is symbolizing it.

[Copilot]

@copilot, no, GetAddressInformation would not do it. That API also checks the address for strings at the address, which is not relevant for this purpose. The symbolization of the address should be t...

Updated to use the exact same approach as the stack trace widget. Now retrieves function information directly from the current thread's first frame instead of using GetAddressInformation().

New approach:

1. Get active thread frames: GetFramesOfThread(activeThread.m_tid)
2. Use first frame for current execution context: frames[0]
3. Apply same formatting logic as FrameItem constructor
4. Handle WinDbg module!function format removal
5. Calculate offset: frame.m_pc - frame.m_functionStart

Benefits:

• No irrelevant string analysis
• Uses exact frame data from debugger
• Perfect consistency with stack trace display
• Handles WinDbg format properly

Commit: 6005886