On 10/04/2014 15:06, Bernd Mueller wrote:
Martin Frb wrote:
gdbserver seems to have some options to track problems, maybe try them?
Options:
--debug Enable general debugging output.
This is very strange. If I activate --debug, then everything seems to
work. As if slowing down the target (by printing all the debug
messages in its console) is helping somehow with the communication.
Odd, that makes it even more look like a gdb bug.
Though, I am not sure it is communication, it might be timing on the
local interaction between gdb and the debuggee.
It is well possible that the connection with the win2000 also affects
speed, and that gdbserver may hit a race condition. (gdb has one on
win32 where it fails to step, because it interrupts the target, before
the target fully resumed / well something roughly like that).
It is possible that the arm gdbselver has is own race condition. And
that the connection speed with win7 increases the likelyhood.
But of course that is just a guess.
You can also try the following.
Rebuild the IDE. Then in the log, watch out for
>> TCmdLineDebugger.SendCmdLn "n &"
This is the log:
>> TCmdLineDebugger.SendCmdLn "n &"
<< TCmdLineDebugger.ReadLn "&"n &\n""
<< TCmdLineDebugger.ReadLn "^running"
Yes, that means it runs async (so the gdb mi implementation is simple
incomplete. Something that affects the local gdb, but not gdb server.)
then wait till the error happens, and see what happens if you press
pause.
Then the assembler window pops up. But I have the impression, that
IDE/Debugger and target are not in sync any more. But maybe, I am
doing something wrong. I have to check this in detail.
Check the thread window, and stack for each thread.
But as I said above it is possible that gdbserver screwed up, and that
your target ended up in an unusable state.
I do no think (but again its all guessing), tha the communication is broken.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
