Forum > Debugger
FpDebug /AVR follow up:
Martin_fr:
--- Quote from: ccrause on October 14, 2019, 01:54:38 pm ---
--- Quote from: Martin_fr on October 13, 2019, 09:42:13 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)
--- End quote ---
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.
--- End quote ---
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:
* IDE: ide/DebugManager and debugger/*
* DebuggerIntf: The base class for the backend.
* LazDebugger***: The backend (gdb/lldb wrapper / FpDebug wrapper) components/lazdebuggers/* and components/lazdebuggergdbmi
* FpDebug (package): (if used)
The package FpDebug contains:
* Dwarf Reader: Currently elf, windows, and mac
* Dwarf Parser: Independent of platform (OS/CPU). Can have dependent subclasses (such as for FPC)
* Controller: Run/Pause/Stepping: Has platform dependend subclasses
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)
ccrause:
--- Quote from: Martin_fr on October 14, 2019, 02:14:25 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.
--- End quote ---
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:
* Read/write registers
* Read/write memory (with a bit mask used to denote the different memory spaces for avr)
* Run control: continue, step, breakpoint insert/delete, program interrupt/pause
--- Quote ---Also a dwarf reader for the exe format involved.
--- End quote ---
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
--- End quote ---
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)
--- End quote ---
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)
--- End quote ---
I think I'll start with the disassembler and see how things develop from there...
Martin_fr:
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.
ccrause:
--- Quote from: 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.
--- End quote ---
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.
ccrause:
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
Navigation
[0] Message Index
[#] Next page