Recent

Author Topic: Help me collect debug-issues  (Read 6121 times)

Joost

  • Newbie
  • Posts: 2
Help me collect debug-issues
« on: January 04, 2022, 11:43:02 pm »
Hi all,

I still want to improve the debug-experience on Free Pascal applications Because let's face it, debugging in Lazarus is still 'less then optimal'. Despite the huge efforts of several developers.

But when one of those developers spend his time on debugging libraries with fpdebug, while the majority of the users do not need that functionality, this is a waste of time. (Well, I needed it myself)

So, to improve the DAB-debug adapter based on fpDebug I need a list of things that ruin the debug-experience. I hoped we can make such a list in this thread. Please don't discuss the issues here, if you want to do that, start another thread. Also do not reply on issues that you also encountered. Maybe we can add a poll later.

And I do not want to have a biased start, so I do not start myself.

Thanks for the help.

[Edit fixed broken web link]
« Last Edit: January 05, 2022, 02:39:22 am by trev »

440bx

  • Hero Member
  • *****
  • Posts: 2753
Re: Help me collect debug-issues
« Reply #1 on: January 12, 2022, 12:21:24 pm »
At the Pascal source level, there is nothing I would go as far as saying "ruins the experience".  There are some rough edges here and there but, usually quite manageable.

That said, at the assembly level - which is where I do a lot of debugging - neither FpDebug nor GDB (as used in Lazarus) can be considered even adequate.  Basically, at the assembly level, they are unusable (except for getting run time short assembly code listings.)

I realize I'm not the typical user.  My "wish list" isn't likely to be of much use to programmers who debug at the Pascal source level but, since you asked, I thought I'd mention it. :)


FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

ccrause

  • Hero Member
  • *****
  • Posts: 568
Re: Help me collect debug-issues
« Reply #2 on: January 12, 2022, 02:48:24 pm »
So, to improve the DAB-debug adapter based on fpDebug I need a list of things that ruin the debug-experience. I hoped we can make such a list in this thread.
I'm a bit confused about where your project fits into the Lazarus scheme.  It appears that you implement a DAB server, i.e. something that feeds information to a debugger frontend/IDE like VSC and Lazarus. The DAB server is based on fpdebug, and Lazarus can also use fpdebug via LazDebuggerFp (or whatever the name of the fpdebug based Lazarus debugger is %)).  So in what ways would an improved DAB server imrpove the Lazarus debug experience?

Regardless of whether the limitations are on the Lazarus frontend or backend side, some feature requests/wishes:
  • Better annotation of disassembly listing
  • Stack viewer, with a bonus if it annotates view with an ABI interpretation
  • Complex data viewer/explorer for arrays, records & classes.
  • Better or configurable display of call stack parameters

Loesje

  • Full Member
  • ***
  • Posts: 168
    • Lazarus Support website
Re: Help me collect debug-issues
« Reply #3 on: January 12, 2022, 06:05:42 pm »
Thanks, 440bx. Debugging a the assembly-level added to the list. (Although indeed not a common case, I would say)

Loesje

  • Full Member
  • ***
  • Posts: 168
    • Lazarus Support website
Re: Help me collect debug-issues
« Reply #4 on: January 12, 2022, 06:51:23 pm »
I'm a bit confused

I can imagine. First of all I shouldn't have send the original message from the 'Joost' account, the browser was logged in and I assumed it was the correct account.

The FPDServer (The DAB adapter) uses FpDebug and improvements on the FPDServer also involve FpDebug. Such improvements could also be ported to the internal-fpdebug debugger. I've choosen to work on the FPDServer because the code-base is smaller and easier to adapt. And it helps more Freepascal developers as it also works on other IDE's.

To make it possible for Lazarus-users to use FPDServer, I've added a DAB-frontend in Lazarus. (You can now debug Python applications in Lazarus)

The biggest visual difference between the DAB-debugger in Lazarus and other debuggers, is that the DAB-debugger shows variables, classes, arrays and such in a treeview-manner. See here for an example. The idea is to bring this functionality also to the other debug-backends, but that's a complex task.

About your list, what is the difference between the second and fourth option?

ccrause

  • Hero Member
  • *****
  • Posts: 568
Re: Help me collect debug-issues
« Reply #5 on: January 12, 2022, 09:41:02 pm »
About your list, what is the difference between the second and fourth option?
The fourth item refers to the call stack display in Lazarus, see attachment for the view. Note the awkwardness of displaying class information passed as parameters.  I'm not sure if this can be improved, it is just not easy for me to digest the information.  Of course for simple parameters it looks fine.

fblu

  • Newbie
  • Posts: 4
Re: Help me collect debug-issues
« Reply #6 on: January 14, 2022, 03:59:59 am »
I think some quality-of-life features would be nice. Their absence isn't a deal breaker, but they would be convenient.

Watching and editing the contents of a list while debugging. I'm aware it's possible to use "stringlist.FList^[0].FSTRING" on the watch, but it would be more intuitive, especially for lazarus newcomers, if you could just type stringlist[0] to access the item value, just like you do in the source code.
Also, when you see content of a stringlist using FList^, the value is shown as something like "ANSISTRING($00000001003ADC20) '1'", instead of just showing "1".

In the evaluate/modify window, there's a field where you can input a new value to the variable you're watching, but it often doesn't work and it doesnt say the reason it doesnt work. With lists or normal variables, I usually can't their values while debugging.

Watching the variables of objects. Both in the watches, and also when I hover my mouse over the source code. For example, supposing I have a TEdit called edit1, it would be convenient if I could access the content of edit1.text using a watch; or when hovering over a "edit1.text" written somewhere in the source code, just to quickly check what's inside. That already works very well with variables, but not with classes.







marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9979
  • FPC developer.
Re: Help me collect debug-issues
« Reply #7 on: January 21, 2022, 02:56:13 pm »
For me the most important usability issues:

  • the evaluation of expressions nice and more native, already said
  • the display of values and expressions in a more normal format (strings etc) already said
  • tracing into low level RTL routines when stepping into a function (e.g. because one of the parameters has a string that needs conversion )

more minor issues:


  • gdb doesn't have AVX registers (ymm), and the register windows is horrible. (a dump of a union, and changes to the window are not persistent)
  • fpdebug has no SSE registers at all, so no way to debug SIMD or floating point on Win64

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7865
  • Debugger - SynEdit - and more
    • wiki
Re: Help me collect debug-issues
« Reply #8 on: January 21, 2022, 05:36:31 pm »
Custom Dwarf tag to differentiate between

- AnsiString (LongString) and PChar / array of char
  https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39582

- ShortString and "record" (or Pchar / or other currently used work-around encodings)


Custom Dwarf info, about search order for global vars in other units.

Currently, there is no info which units are used by the current unit. (And subsequently also not in which order / Or at which scope: interface or implementation).

If an Identifier is not found in the current unit, but exists in several other (or even just one other) units, then the debugger can not tell what is visible under Pascal scoping rules.

I think FPC currently uses DW_AT_external if a symbol is declared in the interface part. That can be used to ignore "symbols declared in the implementation part".
=> But this should be "documented". I.e. it should be ensured this will remain like this in future.

Not sure how to handle:
Code: Pascal  [Select][+][-]
  1. unit Foo;
  2. interface
  3. uses Bar; // Bar "exports" type TSome
  4.   var S1: TSome;
  5.  
  6. implementation
  7. uses OtherBar; // OtherBar "exports" a different type TSome
  8.   var S2: TSome;
  9.  
I believe (at least on some platforms), a copy of each TSome will be added in the current unit. (at least if it is a type). Otherwise the lookup becomes tricky.


Dwarf info, about scopes for nested procs => e.g. info where (unit/line) the variable was declared.
Code: Pascal  [Select][+][-]
  1. var a, b: integer;
  2. procedure Outer;
  3. var a: integer;
  4.  
  5.   procedure Inner;
  6.   begin
  7.      a := 1;
  8.      b := 1;
  9.   end;
  10.  
  11. var b: integer; // not in scope for Inner
  12. begin
  13. end;
  14.  
If paused in "Inner" then evaluating
- a => returns the local var of of Outer => Correct
- b => returns the local var of of Outer => Wrong



zamtmn

  • Sr. Member
  • ****
  • Posts: 474
Re: Help me collect debug-issues
« Reply #9 on: January 21, 2022, 07:29:02 pm »
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39584 It's drinking my blood. I do not know whose problem it is, lazarus or fpc

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7865
  • Debugger - SynEdit - and more
    • wiki
Re: Help me collect debug-issues
« Reply #10 on: January 26, 2022, 01:45:15 pm »
Adding to custom dwarf tags:

For win seh
- finally subroutines to have a reference to the procedure/method that they belong to (this could also be used for nested and recursively nested procs).
- finally subroutines to have the same locals as the procedure they belong to (fpdebug could find the belonging proc, but other debuggers will currently not show locals => despite having the correct basepointer)

About the earlier nested proc request (line info on declaration of proc and vars...) => Actually dwarf 3 location expressions can calculate variable locations in the parent frame "$parentfp". So each nested proc, can simply have its own full list of local vars (including those, it sees from the outer scope(s))

Lansdowne

  • New Member
  • *
  • Posts: 15
Re: Help me collect debug-issues
« Reply #11 on: January 30, 2022, 10:02:36 pm »
I have been using Pascal since Delphi 4 (actually longer than that) so I am not a new user.  But unlike the first reply to this topic, I almost never want to use 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.'

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.

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.

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 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.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7865
  • Debugger - SynEdit - and more
    • wiki

kensmith

  • New Member
  • *
  • Posts: 11
Re: Help me collect debug-issues
« Reply #13 on: April 12, 2022, 01:29:14 am »
Hi all,

I still want to improve the debug-experience on Free Pascal applications Because let's face it, debugging in Lazarus is still 'less then optimal'. Despite the huge efforts of several developers.

I would rate it as "better than most" as it stands but here are a few things I have bumped into.
1) Making a breakpoint with a condition like "not MyBooleanThing" seems not to work.
It always breaks.  Windoze-10 machine.

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

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.
 :(

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.
 8-)

Laksen

  • Hero Member
  • *****
  • Posts: 696
    • J-Software
Re: Help me collect debug-issues
« Reply #14 on: April 12, 2022, 02:26:06 am »
When stepping through code/assembler often times registers aren't updated or updated randomly.

 

TinyPortal © 2005-2018