Recent

Author Topic: fpdebug stand-alone ?  (Read 4071 times)

af0815

  • Hero Member
  • *****
  • Posts: 771
Re: fpdebug stand-alone ?
« Reply #45 on: November 21, 2021, 08:53:34 pm »
fpd should focussed on pascal and not to mimic gdb with the wrong focussed interfaces. fpdebug is IMHO on the rigth way NOT to use gdb compatibility and use a pascal way.

It will be easier for people who knows gdb to change, but if fpd is gdb compatible it will be only a more or less fork. And the major differences from C style to Pascalstyle will be lost.

I think, if you want to debug a pascal program it is the best you use a real pascl style debugger. I have seen on QNAP Nas it is a hell to work with gdb direct and it C like infomations.
« Last Edit: November 21, 2021, 08:56:05 pm by af0815 »
regards
Andreas

ccrause

  • Sr. Member
  • ****
  • Posts: 481
Re: fpdebug stand-alone ?
« Reply #46 on: November 21, 2021, 09:33:47 pm »
fpd should focussed on pascal and not to mimic gdb with the wrong focussed interfaces. fpdebug is IMHO on the rigth way NOT to use gdb compatibility and use a pascal way.
I agree with the sentiment to not blindly clone the gdb interface. However there are certain actions which are virtually universal in debuggers like step, continue, manage break points and so forth. My preference is that, where convenient, follow an existing convention. But, a hex address in the Pascal world starts with a $, so this should stay.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7520
  • Debugger - SynEdit - and more
    • wiki
Re: fpdebug stand-alone ?
« Reply #47 on: November 21, 2021, 10:00:20 pm »
In general Terms:

The fpd example project is and will be for the use with Pascal.

Pascal/Language agnostic commands can be based on gdb syntax.E.g
Code: Text  [Select][+][-]
  1. b file:line

However, gdb has some input forms that I would prefer not to burden on new users.
Code: Text  [Select][+][-]
  1. break func if a = 10
That should use the extended to match the idea from
https://sourceware.org/gdb/current/onlinedocs/gdb/Explicit-Locations.html#Explicit-Locations
(lldb afaik also use -options)
Code: Text  [Select][+][-]
  1. break -function func -cond a=10
(or quotes, if there must be spaces)

Also interactive querying should be optional (i.e "fpd --iact" to enable)
https://sourceware.org/gdb/current/onlinedocs/gdb/Ambiguous-Expressions.html#Ambiguous-Expressions


Ideally the "command interpreter" is kept exchangeable. So different ones can be used. Then the default can be moderate, and the user can load a command set: "fpd --cmd=foo"



As for none Pascal:

The entire core of FpDebug is language agnostic. It is Dwarf2, and parts of Dwarf3 and more Dwarf to come.

The core has an optional extension, to detect FPC generated info, and to "fix" fpc oddities.

Pascal happens in 2 places, and both are plug-able, each just one unit:
- the parser
- the printer

Shipping a parser/printer for C would not be a problem. It would hardly take much space, and using/compiling it could be entirely optional "$IFDEF".

The pascal parser also is a bit lenient. It does for example accept 0xabc123. This token can not appear in Pascal, and it therefore is clear what the user wanted.

af0815

  • Hero Member
  • *****
  • Posts: 771
Re: fpdebug stand-alone ?
« Reply #48 on: November 21, 2021, 10:04:16 pm »
thx to martin for the information
regards
Andreas

Fred vS

  • Hero Member
  • *****
  • Posts: 2513
    • StrumPract is the musicians best friend
Re: fpdebug stand-alone ?
« Reply #49 on: November 21, 2021, 10:07:28 pm »
fpd should focussed on pascal and not to mimic gdb with the wrong focussed interfaces. fpdebug is IMHO on the rigth way NOT to use gdb compatibility and use a pascal way.

It will be easier for people who knows gdb to change, but if fpd is gdb compatible it will be only a more or less fork. And the major differences from C style to Pascalstyle will be lost.

I think, if you want to debug a pascal program it is the best you use a real pascl style debugger. I have seen on QNAP Nas it is a hell to work with gdb direct and it C like infomations.

Hello af0815.

Did you already try fpd ?
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/components/fpdebug/app/fpd

There is a Lazarus project lpi file included.
Maybe you could take a look, compile, run and test it.

This project was last developed in 2009 (with some commits here and there later).
When I tried it last week, it did not compile and was Windows only compatible.

This is the header of fpd.lpr by the original creator: Marc Weustnik:

Quote
---------------------------------------------------------------------------
 fpd  -  FP standalone windows debugger
 ---------------------------------------------------------------------------

 fpwd is a concept Free Pascal Windows Debugger. It is mainly used to thest
 the windebugger classes, but it may grow someday to a fully functional
 debugger written in pascal.

 ---------------------------------------------------------------------------

 @created(Mon Apr 10th WET 2006)
 @lastmod($Date$)
 @author(Marc Weustink <marc@@dommelstein.nl>)

 ***************************************************************************

Of course you may let it as is it.

But also think positively to make it on the run for today.
And following some "classical" commands used by lot of debuggers dont hurt the Pascal mood, imho.
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs

Fred vS

  • Hero Member
  • *****
  • Posts: 2513
    • StrumPract is the musicians best friend
Re: fpdebug stand-alone ?
« Reply #50 on: November 24, 2021, 05:59:46 pm »
Quote
I dont know if it could be possible to make fpd enough compatible with gdb so that all other applications that use gdb could choose fpd vs gdb without any change (apart change the name+path of the debugger used).

That wont be that easy. And I don't think it fits into the space or target of fpd.

Making the existing command have the same NAMES as gdb, may be do-able.
Even adding mi versions of it.

But then....
- Gdb has plenty of config/options that can be set. Not happening.
- The input of the command name is on thing.
  The parsing of expressions is another. FpDebug expects Pascal, not C.
   Yes, a new Parser could be added.
- The output: FpDebug prints pascal..... Not C, Not MI-data.

And I am sure more details would emerge...

Hello Martin.

Yes, indeed, I jumped into --interpreter GDB things, not easy.

Quote
Making the existing command have the same NAMES as gdb, may be do-able.
Even adding mi versions of it.

I did play with fpd adapting the command name to mi version and it works.
fpd responds OK to the order from Lazarus.

But it is not (yet) the case of Lazarus that does not catch the answers from fpd.

All this to confirm that it is absolutely doable.
And that it is absolutely not in priority.

Having a working stand-alone command line debugger is just perfect and mi-versions are for tomorrow.

Fre;D
« Last Edit: November 24, 2021, 06:03:59 pm by Fred vS »
I use Lazarus 2.2.0 32/64 and FPC 3.2.2 32/64 on Debian 11 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt.

https://github.com/fredvs
https://gitlab.com/fredvs

 

TinyPortal © 2005-2018