FpDebug Breakpoints question

[440bx]

Hello,

I've noticed that if I place a breakpoint in an "inline" function, the breakpoint shows as being invalid.

My question is: is it really invalid to place a breakpoint in an inline function/procedure or is it a bug ?

(I suppose it could be considered invalid because a breakpoint in an inline function implies a breakpoint in the equivalent location every place the function/procedure is invoked, if that is the case then, it would be nice if FpDebug eventually supported breakpoints in inline functions/procedures... though after giving it some thought, it may not be possible - depends on what information about inline functions the compiler makes available to the debugger - just thinking out loud on a keyboard.)

suggestion: if supporting breakpoints in inline functions is not possible, it would be nice if the debugger would show a message box warning the user that there are breakpoints in inline functions/procedures that will never be triggered.

[Marc]

My guess is that the corresponding line info isn't copied in the debug ingo when a piece of code is inlined.
Showing a dialog on unreachable code.... I don't know. The debugger doesn't know that this piece of code is inlined. It only knows it has no debug info, similar to other unreachable code.

[440bx]

It only knows it has no debug info, similar to other unreachable code.

I'm thinking that knowing there is no debug info for that code yet there is a breakpoint in it might be all that's needed to show a message box informing the user of the situation.  That's my guess.

[Martin_fr]

For the debugger there is no difference between a breakpoint in an "inline" function, and a breakpoint on a comment.

In both cases, the breakpoint is on a line for which the compiler has not generated line-info. So the debugger only knows, there is no code there.

The spec would allow the compiler to generate line info (even including info that it is inlined) and give all the addresses where there is code for that function.
Mind that it is not only the addresses for the code, but also the info about local vars. So it is a bit more work.
And well, once the compiler does, the debugger still needs the implementation to read it... But for now, that would not help.

So for now the debugger does not know.

The debugger also does not read the code. It relies on debug info only. (Well the IDE sometimes checks for "with do" if you add a watch).
But even if it did, there is no way to differentiate between an inlined function and dead code (a function that is not called from anywhere). Both don't have line-info.

To make it worse. An inlined function may not be inlined in all cases. Then you get a valid breakpoint, but it only stops sometimes.

[Martin_fr]

It only knows it has no debug info, similar to other unreachable code.

I'm thinking that knowing there is no debug info for that code yet there is a breakpoint in it might be all that's needed to show a message box informing the user of the situation.  That's my guess.

Then you would get such a message for any invalid breakpoint.
But only if they are enabled when you press "Run".

Disabled breakpoint are not checked. But you are in for the surprise if you later enable them. (Which even may be automatic)


And eventually this may break... Because line info can become available when libraries are loaded that have that line info.
I don't recall how "invalidated" breakpoint currently work with that...

Some breakpoints already get a "paused" state instead (if the file wasn't found, rather than the line).
But a dll may have the same file as the main-exe, and had it compiled with {$INLINE OFF}.

[Martin_fr]

I am currently not convinced that a feature in the debugger is needed... (And any request for it would land at the bottom of my list).

But if anything were added to the debugger, then:

- It would have to be optional (off by default)
- It would have to check all breakpoints

I.e. since disabled breakpoints may get enabled, and if that fails the debug session become useless, because finding the issue may rely on stopping at that newly enabled breakpoint. (You may ignore the break for a line until some state is reached).

But if all breakpoints are tested, for some people lots of errors may be reported. E.g. I frequently use disabled breakpoints as "marker". So the will often be deliberately on non-code lines.

[Zvoni]

suggestion: if supporting breakpoints in inline functions is not possible, it would be nice if the debugger would show a message box warning the user that there are breakpoints in inline functions/procedures that will never be triggered.

Possible workaround: encase the "inline"-directive in an IFDEF

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

1. Procedure Foo;{$IFNDEF DEBUG}inline;{$ENDIF}

With DEBUG being from Debug/Release-Mode settings in Lazarus resp. compiler-switch (Don't remember the exact symbol-name).

That way during debugging you get everything without having to twist fpdebug, and in release-mode.....

EDIT: Just tested it. Works even as a macro

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

1. {$macro on}
2. {$define MyInline:={$IFNDEF DEBUG}inline;{$ENDIF}}
3.  
4. //{$define DEBUG}
5. Var a:Integer;
6. Procedure Foo(var r:Integer);MyInline      

[Martin_fr]

I have a lot of my units start with

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

1. {$IFDEF INLINE_OFF}{$INLINE OFF}{$ENDIF}

[440bx]

Martin, thank you for the additional details. 

I'll just "un-inline" any function/procedure I need to place a breakpoint in.