Data\Watch Breakpoint by adress

[Martin_fr]

Yes, adding some basic types is on the todo.

But it needs to make sure that it does not have bad effects, if an app defines

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

1. type
2.   integer = record x,y: byte; end;

Yes, that is the worst example. But even now, if you write 16bit code for DOS, then integer = 16bit. And a build in 32 bit integer, must not get into the way of that.

And more, if there is a different "integer", then it is not enough to disable the build in "integer". But it must also disable the build in "pinteger" => because if integer is 16 bits, you don't want a pinteger pointing to 32 bits?

Also those types can be locals. Or the names can be variables....


Yes, Error handling in the debugger is still a big todo.

I usually always add a watch first. Not just for error checking, also it is a quick way, because the watch has "add watchpoint" in its context menu. (and adding the watch, I know ctrl F5 )

[Martin_fr]

And its not only missing types. Its worse
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40173

FPC adds different definition for integer/pinteger. So depending what you are debugging, they may even give unexpected results.

The problem is that they are valid types.
The debugger can not know which of the types you try to debug.

If I just decided to hardcoded filter some of them, then I may help some people. But I will have others complaining that they can't use the filtered type anymore....

Maybe some sort of warning system. But that is far from done...

[zamtmn]

The fact that the type may not be what the user expects is less of a problem. here it is enough to show the user the address and the size - he will understand everything. The fact that the type is not available at all is, in my opinion, much worse