Mismatching between Lazarus and standalone gdb when using remote target

[z0rr0]

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?   

Thanks,

[Martin_fr]

On our sourceforge page (Win32/64) are subfolders "Alternative gdb" => try a newer one?
You can also try any other gdb version...

I don't know what causes the issue / I am not familiar with the gdb server protocol. So I can't judge what/why gdb is sending.

[ccrause]

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.

[z0rr0]

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.

Thanks a lot both for the answers! You were right, Lazarus is first setting a breakpoint in PASCALMAIN, and then, when the breakpoint is caught, it sets the reminder breakpoints. This explains why the breakpoints after PASCALMAIN are correctly caugth. However, the breakpoints before PASCALMAIN are never reached although this is a purely sequential code. I completely missed these traces in the log. As you said, If I want to put breakpoints before PASCALMAIN, I would require something like a user-defined InternalBreakStart.   
   

[z0rr0]

Lazarus 2.1.0 with the option gdbsnone as InternalStartBreak works fine to catch breakpoints before PASCALMAIN.