Author Topic: Asm Window / reply to "Re: Help me collect debug-issues"  (Read 1946 times)


  • Administrator
  • Hero Member
  • *
  • Posts: 8100
  • Debugger - SynEdit - and more
    • wiki
Asm Window / reply to "Re: Help me collect debug-issues"
« on: January 30, 2022, 10:52:56 pm »
In reply to a message from "Re: Help me collect debug-issues"

This reply is to help (and/or describe what is known) with the current situation. (That is until such time, when proper fixes are in place)

the assembly level debugger. It pops up when I simply want to debug my Pascal code, and although I can 'step over' or step out' , what I want to do is 'jump back to dry land.'

If that happens when stepping over (F8) a function call:
That is a known problem with the "gdb based" debugger only. (The issue is either caused by GDB, or by something in the debug info created by FPC / the exact reason has never been pinpointed).
- If you need to use the GDB based debugger: Tools > Options > Debugger > backend: In the "property grid", find an activate "FixIncorrectStepOver"
- However, rather than using the GDB based debugger, it is recommended to use FpDebug / LazDebuggerFp
   If you are still on Lazarus 2.0.x then you may have to install the package.
   If you are on Lazarus 2.2.0 then you just need to select it in: Tools > Options > Debugger > backend
   See also and

As for other cases, when the assembler opens...

The most common run time errors are SIGSEGV which might be due to accessing a char S[1] of an empty string, or a StringList or other object not yet created, or column 6 of a grid that only has 6 columns, you know the usual things, so I need the debugger to place a cursor on the last line of MY code that was processed, which usually gives me a clue what I have done wrong.

The debugger has some code that should find the first stack-frame with Pascal code.
- Of course that is if the stack has a frame with Pascal code.
- That search might be limited to a small number of stack-frames at the top of the stack.
So indeed, this may not always work.

This is on the TODO (and unfortunately has been there for a longer while).

I also find sometimes that the 'Call Stack' only contains assembler/memory addresses and no actual Pascal unit/procedure names, or standard units/procedure names and none from my actual program. so no help in finding out what task was in progress when the error came.

As for "stack has a frame with Pascal" => If the stack ends early (no more frames at all):
- This can happen with GDB and FpDebug
- For the stack-unwinding: GDB is often better than FpDebug (GDB may return more frames than FpDebug)

One (of many issues):

Also todo...

Most of the time I don't even want to step through the code of the standard Lazarus units, just my own code.  Simply, I think the debugger should only place the user in assembler debug if they have specifically asked for it.

Compile the LCL and packages without debug info.
1) Menu: Tools > Configure Build Lazarus => Ensure to chose a profile without debugging (no -gw -gs -g?? switches)
2) Ensure those packages do not have debug info enabled (package options)

Or maybe easier: Project Options > Additions and Overrides (search wiki): New entry for *all* packages, but not the project: -g-
(not tested, but I think it should do)

As you might guess I haven't explored the options for debugger, no doubt there is one that would banish the assembler panel for ever, but my proposal is that should be the default.

The only option is to "auto close" it, if you continue debugging.

The reason why there is no other option is that if your program gets paused in the debugger, the debugger needs to show you some location.
Well ok, that could be disabled, but then the debugger just pauses your app, and you are no wiser. There would be no location, on indication, no nothing....

Obviously, if a Pascal code location can be found, that should be found. So this is where fixes need to happen.

In rare cases, this may not be possible. E.g. if you app crashes, because the stack got totally corrupted. Then the only thing the debugger can find is the current instruction pointer (to an asm instruction). If that asm instruction is not in any known Pascal source, well then nothing can be found.

In the majority of cases, that is not the case. Something could be found. But the debugger is not smart enough. (Or if it relies on GDB, gdb may not have been smart enough).

Anyway, there certainly are cases that can be fixed.

Depending on which of the above case you experience, you should try which of the 2 debuggers (gdb / fpdebug) is better for you.

The other thread "Re: Help me collect debug-issues" is about the "dab debugger" (an add on to Lazarus, not part of the distro) - But issues collected there also apply to the FpDebug debugger. (Same code base).
Some fixes may be independent of the chosen debugger.  (and may be fixed for fpdebug and gdb...)

You can always report specific examples (including mentioning if you use gdb or fpdebug, and what OS you have).

They should ideally come with a ready to test mini/sample project, that reproduces them.

It can then be checked in which category each of them falls. (And if they are know issues)


  • New Member
  • *
  • Posts: 17
Re: Asm Window / reply to "Re: Help me collect debug-issues"
« Reply #1 on: January 31, 2022, 02:15:34 am »
Thank you for the detailed reply, which I'm sure will be useful to others as well. I will have a look at the gd  vs fpdebug suggestion.

Of course, the title of the other thread "help me collect debug issues" made that seem the ideal place to make my points.


  • Administrator
  • Hero Member
  • *
  • Posts: 8100
  • Debugger - SynEdit - and more
    • wiki
Re: Asm Window / reply to "Re: Help me collect debug-issues"
« Reply #2 on: January 31, 2022, 03:27:09 am »
Of course, the title of the other thread "help me collect debug issues" made that seem the ideal place to make my points.

Your post is (IMHO) still fine in the other post. (might affect the DAB, fixes might affect the IDE' build in.... might)

From the initial post of the other thread
So, to improve the DAB-debug adapter based on fpDebug

1) That DAB-debug can be plugged into lazarus, it brings it's own frontend, but the backend is the same (FpDebug).
So some fixes there will affect the IDE's LazDebuggerFp. The rest will be avail through the add-on.

2) As you noted, Joost is not the only one reading the thread.
I am also interested. (And planning to fix some of it)


  • Administrator
  • Hero Member
  • *
  • Posts: 8100
  • Debugger - SynEdit - and more
    • wiki
Re: Asm Window / reply to "Re: Help me collect debug-issues"
« Reply #3 on: April 12, 2022, 02:35:52 am »
Change of topic / next reply from related thread

1) Making a breakpoint with a condition like "not MyBooleanThing" seems not to work.
It always breaks.  Windoze-10 machine.

Are you sure you use FpDebug? Can you give an example?
Menu: Tools > Options > debugger backend

Also OS / Bitness?

On MacOs this may not work. Here breakpoints are handled by lldb, and I am not sure which conditions (if any at all) work.

2) On string variables it would be nice if you could view a range of characters from the string.

- Originally this was meant to be done (but has not yet) via MyString[5] and RepeatCount=10.
- But personally, I fancy to also add a Syntax like MyString[5..14]

Actually on my personal todo list...

3) If a variable is passed as a VAR to functions several deep, it would be nice to be able to view it but it seems the information needed is not available so it refuses.
Again, sure you use FpDebug?

If it is "var a: variant" => use dwarf-2. (Otherwise / if you don't use variants, use dwarf-3 (for FpDebug))

Also: while stepping, if you are on the begin or end line of a procedure/method/function => (local) variables are not yet initialized.
(Ideally stepping should not even go to such a begin line...)

Certain functions in the RTL have an optimization "skip stackframe generation" => those will not show any locals correct, and they will hide their caller in the stackframe.

In some cases locals can be wrong when you compile with -O1.
It does happen rather rarely, but to be save use -O- (optimization level 0 / zero)

On Win32/64 "finally" blocks are hidden subroutines. The debugger does not show locals in such hidden subroutines.
(Actually FpDebug in Lazarus 2.3 does have a fix for this, but only in some cases yet)

4) An "extra cheap profile" function would be nice.  All it really needs to do is count how many times your code went through a given breakpoint and do the difference in the NOW between two breakpoints.
When narrowing down a time eater, this will save having to edit code to add the lines to make the tests needed.
I know about where the extra half and hour in my code is going but not exactly where.

If you can get Linux for testing (e.g. a VM) => use:
  valgring --tool=callgring
then display results in kcachegrind.

But as for the question: Breakpoint do have a hitcounter.
You can see it:
- in the breakpoint properties
- the breakpoint window.

In the breakpoint properties, you can un-check the "break" property. Then the breakpoint will not pause => just count.

And if you want it a bit faster:
- Close all Stack/Watches/Locals/Thread/Asm windows
  (Or for those that have it, alternatively disable their power-button)
- Open the "History" window (menu view > debug windows > history)
  Disable it via the power button.

If you don't disable history, then all watches and stack are computed on each hit of the breakpoint.


  • Administrator
  • Hero Member
  • *
  • Posts: 8100
  • Debugger - SynEdit - and more
    • wiki
Re: Asm Window / reply to "Re: Help me collect debug-issues"
« Reply #4 on: April 12, 2022, 02:41:08 am »
When stepping through code/assembler often times registers aren't updated or updated randomly.

Can you test with Lazarus 2.3 ?

I did some changes
Code: Text  [Select][+][-]
  1.  448ccc8ca179ab6a97d2bebebf600e28b6280e1d
  2. * Debugger: Registers, clear incorrectly cached values. Fix wrong value shown, if display-format is changed.

Though that only affects if you changed the display format (dec/hex/...)

Also In Laz 2.2 there is no green dot for registers that did change.

Otherwise would be good to have steps to reproduce.

OS? Bitness?


  • Hero Member
  • *****
  • Posts: 697
    • J-Software
Re: Asm Window / reply to "Re: Help me collect debug-issues"
« Reply #5 on: April 12, 2022, 02:13:29 pm »
Cool, will check


TinyPortal © 2005-2018