Hello everyone, I am getting some mismatching between debugging from Lazarus(2.0.10 and gdb 7.3.50) and standalone gdb(7.11.1). I have attached two files. One contains the log of the gdb(7.11.1) and the other is the log when Lazarus uses gdb(7.3.50) in Windows. I observe that breakpoints are never caught when are set by Lazarus. These are the commands I am using to configure gdb from Lazarus:
"--eval-command="set debug remote 1" --eval-command="set arch i386:x86-64""
Only the breakpoints that are in the main program are successfully caught (you can see a video here https://twitter.com/ToroKernel/status/1361814322725351425?s=20). Also, I am developing my own gdbstub so I am not really sure if this mismatching is due to something I did wrong. Do you have any clue about what is going on?
It would be easier to spot differences if you tested the same version of gdb in standalone and Lazarus. Even the very first gdb actions following
target remote... are slightly different between the two versions. Not that I think that is the problem.
By default Lazarus inserts a break point at the entry point to
main as the very first break point. When the target halts at this break point, Lazarus sets the user break points (and other break points to catch errors etc.). I suspect you want to break before
main (I'm not familiar with the code you are debugging)? If so maybe another InternalBreakStart type is needed that can be set to the entry point of the executable image, or perhaps the _START symbol (not sure if FPC emits this for all the targets). Martin would have an idea of how practical this would be.
Your gdbserver stub seems OK since the standalone gdb session seems to receive the expected information. You can compare the returned memory content against a disassembled view of the executable image to check if the memory content is reported correctly by the stub. To test the register information could be done by writing some assembly code to fill the registers with known values. Break inside this code and compare the returned register info.