Refresh TUI source panel after "monitor reset"

Refresh TUI source panel after "monitor reset"

[R. Diez]

Hi all:

I have been using GDB with OpenOCD for quite a while in order to program and debug embedded software on an STM32 microcontroller.

I have learnt that, after a "monitor reset halt" (which resets the CPU), GDB still keeps the cached values of the CPU registers, but you can workaround it with command "flushregs".

There is one thing that is still bugging me though: in TUI mode, the source pane does not refresh until the current instruction is executed.

Is there a way to refresh the source pane after "flushregs"? I tried "maint flush source-cache" and "refresh", but they did not help.

Thanks in advance,
   rdiez

Re: Refresh TUI source panel after "monitor reset"

[Andrew Burgess]

"R. Diez via Gdb" <gdb@sourceware.org> writes:

> Hi all:
>
> I have been using GDB with OpenOCD for quite a while in order to
> program and debug embedded software on an STM32 microcontroller.
>
> I have learnt that, after a "monitor reset halt" (which resets the
> CPU), GDB still keeps the cached values of the CPU registers, but you
> can workaround it with command "flushregs".
>
> There is one thing that is still bugging me though: in TUI mode, the
> source pane does not refresh until the current instruction is
> executed.
>
> Is there a way to refresh the source pane after "flushregs"? I tried
> "maint flush source-cache" and "refresh", but they did not help.

Completely untested, but I wonder if 'list *$pc' does what you want?

Thanks,
Andrew

Re: Refresh TUI source panel after "monitor reset"

[R. Diez]

> Completely untested, but I wonder if 'list *$pc' does what you want?

Thanks for the hint.

The "list *$pc" command seems to have no effect at all, at least when using TUI.

I tried this sequence:

monitor reset halt
flushregs
list *$pc

And neither the source nor the disassembly pane changed.

But then I experimented a little further. Command "list" seems to work if you supply a known function name. If the function does not exist, you get an error message like 'Function "test" not defined.'.

However, if you specify an address which does not fall in the known code area, GDB just ignores the "list" command. For example, I tried these commands:

list * 0x1000000
list * 0x8000000

And there were just silently ignored.

The reset address does not fall into the current firmware, but in the bootloader area, and the currently-loaded ELF does not have debug symbols for the bootloader area. That is perhaps the reason why the "list *$pc" has no effect.

But then your suggestion gave me the idea of trying "disassemble $pc,+10". That did the trick.

Interestingly enough, the current instruction indicator (the '>' on the left) is not showing the current address, even though the PC register is correct. I am trying this on an ARM Cortex-M4F microcontroller. But then running "stepi" does work, and the indicator is then right.

Regards,
   rdiez

Re: Refresh TUI source panel after "monitor reset"

[Pedro Alves]

On 2022-06-24 15:57, R. Diez via Gdb wrote:
> 
> But then I experimented a little further. Command "list" seems to work if you supply a known function name. If the function does not exist, you get an error message like 'Function "test" not defined.'.
> 
> However, if you specify an address which does not fall in the known code area, GDB just ignores the "list" command. For example, I tried these commands:
> 
> list * 0x1000000
> list * 0x8000000
> 
> And there were just silently ignored.
> 
> The reset address does not fall into the current firmware, but in the bootloader area, and the currently-loaded ELF does not have debug symbols for the bootloader area. That is perhaps the reason why the "list *$pc" has no effect.
> 
> But then your suggestion gave me the idea of trying "disassemble $pc,+10". That did the trick.
> 

Did you try just "frame"?  That's what I typically use to make the source pane refocus on the current frame, where
the program is stopped.

Re: Refresh TUI source panel after "monitor reset"

[R. Diez]

> Pedro Alves wrote:
> Did you try just "frame"?  That's what I typically use to make the source pane refocus on the current frame, where
> the program is stopped.

> Andrew Burgess wrote:
> Completely untested, but I wonder if 'list *$pc' does what you want?

I have been investigating a little more. It's been some time, so I'll start from the beginning again.

I have a bootloader and the main firmware. Normally, I program the main firmware with OpenOCD, so GDB knows where the firmware source code is located.

The bootloader on the target does not normally change. It is a different project, its debug information is in a different .elf file, so its source code is not automatically available when I debug the main firmware.

Say I pause execution by pressing Ctrl+C in GDB. The TUI interface shows then the source line that corresponds to the current PC. So far so good.

Now I do a "monitor reset halt", followed by a "flushregs". However, the TUI interface still shows the old source code position. That is misleading.

If I issue command "print $pc", I can see that the PC register was updated fine.

Command "frame" does not help. It prints the right frame address (the same address as the PC), and that is all.

Command "list *$pc" is ignored, because the PC points to the bootloader, and its source code is not available when debugging the main firmware. It is particularly annoying that no hint or error indication is printed.

Command "disassemble $pc,+10" dumps the disassembly on the command pane, and does not really help.

Say you now switch to "layout split" mode. Both the source panel and the disassembly panel still show the old source code position, which is wrong.

If you now issue command "disassemble $pc,+10", then the disassembly panel jumps to the right position, and the source panel (if any) shows "[ No Source Available ]". That is now more helpful.

However, TUI still remembers its internal "current source position", which is still the old (wrong) one. If you now resize the GDB window with the mouse, then both source and disassembly panels jump to the old, wrong position, which is very misleading. After all, resizing the window should not change the displayed addresses.

TUI's internal "current source position" only gets updated after you execute one assembly instruction. I was hoping there was some way to tell GDB to update that "current display position" right after command "monitor reset halt" and/or "flushregs".

Regards,
   rdiez