On 09/06/2019 18:16, Dimitrios Chr. Ioannidis wrote:
> I managed to use an official AVR debugger ( AVR Dragon ) with an
> official gdb-bridge ( Atmel Studio's atbackend.exe ) and I can start a
> debugging session from Lazarus, using a avr-gdb 8.3 ( or the official
> gdb from the Microchip (Atmel) AVR Toolchain ).
> But what am I seeing ( see attached screenshot ) makes me to believe
> that fpdebug ( either dwarf 2 or dwarf 3 the results is the same )
> doesn't know ( needs to know ? ... ) how to interpret the avr platform
> /architecture . Am I correct in my assumption ?
> What is your opinion ?
Yes, fpdebug currently only knows intel.
I assume, this is a linux based platform?
And anything that then accesses the registers.
Registers need to be stored with the correct dwarf index. The index is
used when reading any register based data (including any data relative
to the stack / i.e. local var)
Note, that currently access to StackPointer/Base and InstructionPointer
are hardcoded in other units too (using either the intel name, or the
dwarf reg num for intel)
So that needs to be fixed...
The disassemble currently only does intel too.
Not sure if stepping relies on this. (i.e. identifying "call" instructions)
Stepping needs to be reworked anyway.
On 10/06/2019 01:05, Martin Frb via lazarus wrote:
> Note, that currently access to StackPointer/Base and
> InstructionPointer are hardcoded in other units too (using either the
> intel name, or the dwarf reg num for intel)
> So that needs to be fixed...
I.e. you find code like
if AController.CurrentProcess.Mode=dm32 then
Reg := RegList.FindRegisterByDwarfIndex(8)
Reg := RegList.FindRegisterByDwarfIndex(16);
(evaluating the stack)
RegList should have methods:
And reading the stack, may have to be moved to OS/CPU specific classes,
if stack-frame layout may differ.