Recent

Author Topic: suggestions for asm window  (Read 1988 times)

devEric69

  • Hero Member
  • *****
  • Posts: 648
suggestions for asm window
« on: June 11, 2019, 06:14:45 pm »
I make a suggestion at 2 cents (sometimes...):
- in the CPU \ assembler window, a context menu to "go to the current EIP".
- and another contextual menu "go to Caller" from the EIP (to place a breakpoint there, and observe then what is happening there).
And to be able to do this again, and again, with these 2 menus, until we get back to the line explaining our bug (this would be very useful especially for exceptions and crashes).
« Last Edit: June 11, 2019, 06:18:58 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9867
  • Debugger - SynEdit - and more
    • wiki
Re: suggestions for asm window
« Reply #1 on: June 11, 2019, 06:41:17 pm »
Splitted from the topic "Re: Considerations in the decision of adding a feature to the FPC compiler?" as this post was off topic.

Is this about the FPC textmode IDE?

If it is about Lazarus, I can move it to the correct part of the forum.

devEric69

  • Hero Member
  • *****
  • Posts: 648
Re: suggestions for asm window
« Reply #2 on: June 11, 2019, 08:18:04 pm »
Sorry about the off-topic.
The 2 context menus ("Goto current EIP" and "Goto Caller") are more of a functionality requirement in the window " See \ debug windows \ assembler ", so a debugger feature I guess.

I allow myself this proposal, because being agile with the use of this CPU window is what guarantees success when you start developing a program with a compiled language, therefore close to assembly code, compared to starting in the development of the same program with highly interpreted code where you must necessarily rely on the "resilience" of the sublayer(s) that interpret.
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9867
  • Debugger - SynEdit - and more
    • wiki
Re: suggestions for asm window
« Reply #3 on: June 11, 2019, 11:00:04 pm »
" See \ debug windows \ assembler "

"see" => "View"
And that makes it a Lazarus topic.

For background info, there is a "FP IDE", that works in a dos box, much like old turbo pascal.

---------------------
On the topic:

The asm window, has a green arrow (in front of the input field, on the top toolbar of that window).
This arrow gets you to the current (E/R)IP

Hover with the mouse, to see the description of the button in a hint.



As for going to the caller, you need to use the stack window (from the same menu). Each entry in the stack has a context menu with an entry "view assembler"

If for some reason the stack window is not showing you any caller info, then the stack is unreadable and the info not available. That means that none of the windows could in any way offer you a way to get to the caller.
But if the stack window works normal, then you can get to the asm entry from there.

devEric69

  • Hero Member
  • *****
  • Posts: 648
[Solved] Re: suggestions for asm window
« Reply #4 on: June 13, 2019, 01:51:15 pm »
Thank you: this is exactly what I was looking for, in step-by-step debugging (I saw, that there is even the possibility to set breakpoints directly on each subsequent call, all from this "stack window").
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9867
  • Debugger - SynEdit - and more
    • wiki
Re: suggestions for asm window
« Reply #5 on: June 13, 2019, 02:22:58 pm »
You may also want to explore the "history" window (View > Debug windows > History).

You can set breakpoints (at strategic places), and then right click the breakpoint (or use the breakpoint window) and go to "breakpoint properties".

There you can uncheck "break" => which means the breakpoint will be hit, but your app will be continued immediately (so there is only a short delay, but no real interrupt)
You can check "take snapshot"

All the watches you have in your watch window, will be evaluated. The stack will be evaluated (5 frames). And your app will continue to run.

When and if your app comes to a stop/pause, you can doubleclick entries in the history window, and see what the watches/stack where at that time.

https://wiki.lazarus.freepascal.org/IDE_Window:_Debug_History
https://wiki.lazarus.freepascal.org/IDE_Window:Breakpoints#Breakpoint_properties

 

TinyPortal © 2005-2018