Lazarus

Using the Lazarus IDE => Debugger => Topic started by: Martin_fr on October 14, 2019, 02:14:25 pm

Title: FpDebug /AVR follow up:
Post by: Martin_fr on October 14, 2019, 02:14:25 pm
Or translate LazDebuggerFpGDBMI to use gdbserver.
That should be easy, since it just needs to insert the commands to gdb that set the remote.... (and maybe async gdb commands)
My preference is to move away from gdb since it needs a patch (which has been around since 2016) to work properly with the separate memory spaces of avr.

Well, it is possible to add new backends to the IDE. Including based new one on FpDebug.
I myself have currently no plans to write such a backend, as my TODO is quite full.


The Structure in the IDE:

The package FpDebug contains:


If you want to control gdb-server without gdb, you need to implement everything that the gdb-part does. I.e. I do not know if gdb or gdb-server control the stepping.

To start this is the protocol.
Also a dwarf reader for the exe format involved.
Cpu specific register reader

With that you would be able to read memory, so watches would work.

Then it depends what is needed for running/stopping/pausing ....
ASM single stepping should be fairly easy.
With look line based stepping can build on that, with an added (partial) disassembler... (with luck)

Some of that would go into FpDebug, and patches can be accepted.

The protocol would go into a new backend.

---
Also there is no full support for memory spaces in fpdebug yet. There are one or 2 places where it has prepared code....
However that might not be to hard to change (adding bit offsets to addresses had turned out simple, so adding an address space would hopefully be similar)
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on October 14, 2019, 07:23:26 pm
If you want to control gdb-server without gdb, you need to implement everything that the gdb-part does. I.e. I do not know if gdb or gdb-server control the stepping.

gdb typically controls gdbserver (at least for the cases I am interested in).  The minimum functionality required by gdb to function with a gdbserver stub is:

Quote
Also a dwarf reader for the exe format involved.
The elf format emitted by avr-ld is elf32-avr.  Hopefully the current elf reader can correctly read little endian already...

Quote
Cpu specific register reader
Not sure what this should do. The gdb remote protocol requires gdbserver support for register access.

Quote
Then it depends what is needed for running/stopping/pausing ....
ASM single stepping should be fairly easy.
With look line based stepping can build on that, with an added (partial) disassembler... (with luck)
I think the disassembler is the best isolated bit and would be relatively easy to implement (e.g. the source for fp-avrsim is a good start, it already decodes the machine instructions, one only needs to output formatted text).

Quote
Some of that would go into FpDebug, and patches can be accepted.

The protocol would go into a new backend.

---
Also there is no full support for memory spaces in fpdebug yet. There are one or 2 places where it has prepared code....
However that might not be to hard to change (adding bit offsets to addresses had turned out simple, so adding an address space would hopefully be similar)
I think I'll start with the disassembler and see how things develop from there...
Title: Re: FpDebug /AVR follow up:
Post by: Martin_fr on October 14, 2019, 09:58:19 pm
I shall gladly answer any questions. (Though I will be away for about a week, after tomorrow).

As for reading elf32-avr. Should be easy to test.
components\fpdebug\test\dwarfviewer\dwarfviewer.lpi

You may need to changed some "missing" methods in fpdebug from protected to public (the compile error will tell).

Once compiled, open it, load the avr exe, and see if you see a list of units.
Select a unit, and show symbols (takes a bit of time).

If you get to see them, then that is good.
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on October 19, 2019, 06:30:09 am
I shall gladly answer any questions. (Though I will be away for about a week, after tomorrow).

As for reading elf32-avr. Should be easy to test.
components\fpdebug\test\dwarfviewer\dwarfviewer.lpi

You may need to changed some "missing" methods in fpdebug from protected to public (the compile error will tell).

Once compiled, open it, load the avr exe, and see if you see a list of units.
Select a unit, and show symbols (takes a bit of time).

If you get to see them, then that is good.

The only problem compiling the dwarfviewer program is that one needs to define DwarfTestAccess for TDwarfCompilationUnit.  This can be done by including the fpdbgdwarfdataclasses unit as part of the project and to add -dDwarfTestAccess to the project's custom options. Lazarus complains about the unit being part of a registered package, but this should be ignored.

Loading a test program (.elf) shows the debug symbols and line info, so the dwarf format seems compatible.
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on October 19, 2019, 06:36:01 am
Progress update: avr disassembler unit for testing (https://github.com/ccrause/lazarus/blob/master/components/fpdebug/fpdbgdisasavr.pp)

The disassembler can be tested with the asmtest program after applying this patch: https://github.com/ccrause/lazarus/commit/1efb5d1426a1443233122276367b8651353077f6
Title: Re: FpDebug /AVR follow up:
Post by: Martin_fr on October 19, 2019, 09:07:17 am
I'll have a look when I am back home... Likely early next month
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on December 04, 2019, 03:41:59 pm
I have made a little progress on prototyping support for remote serial protocol (RSP) and AVR in FPDebugger.  Consider the following program:
Code: Pascal  [Select][+][-]
  1. program divtest;
  2.  
  3. var
  4.   ans, x, d: int16;
  5.  
  6. begin
  7.   x := 63;
  8.   d := 3;
  9.   ans := x div d;
  10.   if ans = 21 then
  11.     halt(0)
  12.   else
  13.     halt(255);
  14. end.
Load compiled AVR binary into fp-avrsim:
Code: Bash  [Select][+][-]
  1. ./avrsim -d1234 ~/fpc/fpc-avr/src/tests/div/divtest.bin
Debug with FPDebugger:
Code: Text  [Select][+][-]
  1. ./fpd ~/fpc/fpc-avr/src/tests/div/divtest.elf
  2. FPDebugger on Linux for x86_64 (2019/12/04 16:14:32 FPC: 3.3.1)
  3. Copyright (c) 2006-2009 by Marc Weustink
  4. starting....
  5. Using file: ~/fpc/fpc-avr/src/tests/div/divtest.elf
  6. FPD>r
  7. FPD>b 214
  8. Breakpoint 1 added at address $00000000000000D6.
  9. FPD>c
  10. ####### CHECK False for id 0 stored False False D6 0
  11. Breakpoint reached at .
  12. ===
  13. /home/christo/fpc/fpc-avr/src/tests/div/divtest.pp 10:10 $main
  14.   [$000000000000009E+56]   if ans = 21 then
  15. ===
  16.   [$00000000000000D6]             30912801    lds r19, $0128
  17.   [$00000000000000DA]             20912901    lds r18, $0129
  18.   [$00000000000000DE]                 3531    cpi r19, $15
  19.   [$00000000000000E0]                 2105    cpc r18, r1
  20.   [$00000000000000E2]                 39F4    brne .14
  21.   [$00000000000000E4]                 612D    mov r22, r1
  22. FPD>eval ans
  23. 21
  24. FPD>q
  25. Quitting ...
  26. Killing application ...
  27. Process ended with exit-code 0.
At least some very basic functionality is already working in the stand-alone debugger.
Title: Re: FpDebug /AVR follow up:
Post by: avra on December 05, 2019, 10:28:30 am
I have made a little progress on prototyping support for remote serial protocol (RSP) and AVR in FPDebugger.
This is very nice news. Congratulations! If I didn't invest 20 years in AvrCo I would be hooked.  ;)
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on December 08, 2019, 09:05:35 pm
It is slow, buggy, has a hardcoded tcp port number, needs drastic refactoring... but it works well enough for a screenshot opportunity!  FpDebuggerFpAvr, an extension of FpDebuggerFp to debug AVR microcontrollers over a gdbserver connection.
Title: Re: FpDebug /AVR follow up:
Post by: Martin_fr on December 08, 2019, 09:53:34 pm
wow... impressed.

Is there a way to set up a test env with qemu?
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on December 09, 2019, 06:29:40 am
wow... impressed.

Is there a way to set up a test env with qemu?
I assume you want to use qemu to emulate the AVR target?  I use a simulator fp-avrsim (https://github.com/ccrause/fp-avrsim) to simulate the test program on the AVR target and act as gdbserver. Other options are available such as simavr.
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on December 09, 2019, 12:28:28 pm
Is there a way to set up a test env with qemu?
I don't see official AVR support mentioned in Qemu's wiki (https://wiki.qemu.org/Documentation/Platforms). There do appear to be some active development to support AVR (https://lore.kernel.org/qemu-devel/20191014161843.84845-2-mrolnik@gmail.com/) as a target.
Title: Re: FpDebug /AVR follow up:
Post by: fliegermichl on February 16, 2021, 06:37:40 pm
Progress update: avr disassembler unit for testing (https://github.com/ccrause/lazarus/blob/master/components/fpdebug/fpdbgdisasavr.pp)

The disassembler can be tested with the asmtest program after applying this patch: https://github.com/ccrause/lazarus/commit/1efb5d1426a1443233122276367b8651353077f6

Hi,

I'm trying to find a way to make AVR programs debug.
but i fail even on the step "apply this patch to lazarus".
how can i make that?
Michael
Title: Re: FpDebug /AVR follow up:
Post by: JuhaManninen on February 16, 2021, 08:08:42 pm
I'm trying to find a way to make AVR programs debug.
but i fail even on the step "apply this patch to lazarus".
how can i make that?
https://wiki.freepascal.org/Creating_A_Patch#Applying_a_patch
Title: Re: FpDebug /AVR follow up:
Post by: d.ioannidis on February 16, 2021, 08:47:38 pm
Hi,

< snip >
I'm trying to find a way to make AVR programs debug.
< snip >

Do you want to debug a physical AVR mcu ( i.e. in arduino ) or in a simulator ?

If you want to use a simulator, AFAIK, you can use the simavr in linux. If you're using Windows, you can use from MS7 ( Microchip ( Atmel ) Studio 7 freeware ), the buildin simulator.

PS: If you're on windows, I can help you setup Lazarus ( trunk ) to work with MS7's backend agent ( atbackend.exe ). Then you'll be able to debug AVR programs with MS7's simulator and/or a physical mcu's if you have a debugger ( EDBG, MPLAB SNAP, some xplained boards have mEDBG or nEDBG .etc ).

EDIT : You could read, my little tutorial I wrote, motivated by your question, on how to setup Lazarus to debug AVR firmwares on windows https://forum.lazarus.freepascal.org/index.php/topic,53342.msg394467/topicseen.html#new.

regards,
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on February 17, 2021, 09:12:37 am
Progress update: avr disassembler unit for testing (https://github.com/ccrause/lazarus/blob/master/components/fpdebug/fpdbgdisasavr.pp)

The disassembler can be tested with the asmtest program after applying this patch: https://github.com/ccrause/lazarus/commit/1efb5d1426a1443233122276367b8651353077f6
I'm trying to find a way to make AVR programs debug.
but i fail even on the step "apply this patch to lazarus".
how can i make that?
Michael

Those instructions are a bit out of date.  Most of the previous changes to fpdebug has been merged with trunk, but unfortunately the remote connection details are not exposed, so it is a bit awkward to use.  I'm busy updating the AVR and remote properties - if you like you can test this git branch: https://github.com/ccrause/lazarus/tree/fpdebugger-2021. Since this is still under development there may be a few issues, but of course if you find issues then please report them in this thread (not the bug tracker as this is still an out of tree fork).

Another option is use the gdbserver option in Lazarus (also described by Dimitrios), but then you need a patched  (https://sourceware.org/legacy-ml/gdb-patches/2016-03/msg00318.html)avr-gdb to make addresses map correctly to memory.
Title: Re: FpDebug /AVR follow up:
Post by: fliegermichl on February 17, 2021, 09:23:27 am
Thank you very much!
I will give it a try.
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on February 18, 2021, 11:01:19 am
... I'm busy updating the AVR and remote properties - if you like you can test this git branch: https://github.com/ccrause/lazarus/tree/fpdebugger-2021. Since this is still under development there may be a few issues, but of course if you find issues then please report them in this thread (not the bug tracker as this is still an out of tree fork).
Just a note for those brave enough to test this branch - it has issues building with make because of dependencies not yet properly configured in the makefile and/or packages.  Rebuilding this branch from inside an existing Lazarus IDE does work. Basically copy a working Lazarus executable into this source, open, configure compiler etc. and then click on Tools : Build Lazarus...
Title: Re: FpDebug /AVR follow up:
Post by: ccrause on February 21, 2021, 06:05:51 pm
Just a note for those brave enough to test this branch - it has issues building with make because of dependencies not yet properly configured in the makefile and/or packages.  Rebuilding this branch from inside an existing Lazarus IDE does work. Basically copy a working Lazarus executable into this source, open, configure compiler etc. and then click on Tools : Build Lazarus...
The make issues should be fixed now (at least make all and make bigide works for me).  Note that I started a new branch because there were a whole bunch of changes to reverse, and there were conflicts with upstream changes).  The new branch: https://github.com/ccrause/lazarus/tree/fpdebugger-2021-2
TinyPortal © 2005-2018