Re: How to support interrupting a single step

[email protected]
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
Hi Luis,

I’m sorry, for the very late reply!

> Am 18.10.2019 um 15:08 schrieb Luis Machado <[email protected]>:
> 
> The behavior of GDB when dealing with a tight/endless loop is known. See https://sourceware.org/bugzilla/show_bug.cgi?id=21221.

that Bug describes behavior, that a tide loops can’t be jumped over. In my case, I try to interrupt that scenario. So running the binary, till that loop. Interrupt execution and finding the program counter in that loop. Then single stepping over the loop (either ’s’ or ’n’). Then gdb does not break on the next execution of the loop and I’m unable to break into the debugger again. ctrl-c simply does nothing and I have to kill the debug server, so that the lost connection to the debug server gives me the prompt back.

Debugging the packages send and received, I find following:

^C

00d0030020276f0200b86a0200008c0021d0030020000000000000000000000000000000000000000000000000
remote_pass_ctrlc called
remote_interrupt called
Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD;
Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200ba6a020000980021d0030020000000000000000000000000000000000000000000000000
Sending packet: $s#73...^Cremote_pass_ctrlc called
remote_interrupt called
Packet received: T05hwbreak;thread:0000DEAD;
Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200bc6a020000000021d0030020000000000000000000000000000000000000000000000000
Sending packet: $s#73...Packet received: T05hwbreak;thread:0000DEAD;
Sending packet: $g#67...Packet received: aba50200010000007017000001000000000000000000000000000000d00300200000000000000000000000000000000000000000d0030020276f0200be6a020000000021d0030020000000000000000000000000000000000000000000000000

I would expect that once GDB recognizes, that I want to interrupt execution, it would stop sending ’s’ and ‚g‘ packages.

> The problem of GDB sending lots of 's' and 'g' packets is also known, but i thought it had been fixed a while ago. We tried to harden that mechanism a bit more.
> 
> Are you running an older GDB version by any chance? If not, it may be a good idea to file a ticket so we can take a look at it.

$ arm-none-eabi-gdb -v
GNU gdb (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.0.20190703-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

> It should already be interruptible, but the timing and speed of communications between GDB and the debug server tends to cause problems.

Wouldn’t it be enough, if GDB just stops to execute these ’s’, ‚g‘ package sequences? If not, what do I have to implement on the debug server side, to let my interrupt such a situation?

best regards,

Torsten
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEBlD/pUKd/TvZxxklxPKNInpbSZkFAl5+NJYACgkQxPKNInpb
SZk0Tw//ZjUXIiA8KUDcg8QNNR2gfVw6GMMxj3dufJ3HLnCuZ8E3tKih13qdAFUq
5CISRF0Q6Et22PAJ2PQiNQlUXTdqmqBhhUym7mKZZx4RESXToK2oJ5+srL8EYtPa
mqPL6Nd410uCoC+R4Fe994DsOjY+omZA1PTYQbogGV+psuaoda2cCJIp0YoaOmSW
kxFOU8LKq2AhXvjoTUKfJvVxMISInYFHEEdfLLm7MMEszDjbz9n87rmx7uMkxsA8
dk7ZL8HobgVRTRW1M6ZR1D0UI8Wb4tY9S3jJbBiHNlzQCbve8t0iV8kbcV9xf+ok
vGUKdaUw+I+6Z4Z3taN0fXInEEsUquuRG6PPKUYv3nQ3Gze7JgX3pTX6TBmM7oD2
ub5tYoQ6qSYsp+2WtMWZyG1doY4+Jov+Pbi805iMLTDSC0mSlX73hTatibOH7GBa
Tdf0WB986s4sHI1u3whDsZKrMtw7WJSlBMkMO//WDatyKc4rqIt0xSW7G165/WOt
Io2ryY3cDvue9QeehEbptc5xl/8w8tzWpsBmWDKoAwhoSO4cJ650XqS9liVXl03N
qCPBRjhaqaYMJuLim9XoVUDFw3r72bo6UZ2QsDdPqlOY6jW8/bsRYBFXVj4/5EiP
SwCPakd+/ICaHkF9l8v+/tFKqVrNMTlgLWP9awHl4xJh6gVPjNI=
=aHNi
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.