)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1001667,"name":"Jan Matyas","email":"jan.matyas@codasip.com","username":"JanMatCodasip"},"change_message_id":"7b992342a964a0a500e1493e3c85a8073e4d63b6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f0cfc370_2e336763","updated":"2021-08-24 10:10:52.000000000","message":"Hi, can I provide any further explanation of this fix or was it understandable?\n\nWho would be a good candidate to review the change?\n\nThank you, \nJan\n\n","commit_id":"131420ac649a0027e65d65eb17adeeb96dc9013a"},{"author":{"_account_id":1001667,"name":"Jan Matyas","email":"jan.matyas@codasip.com","username":"JanMatCodasip"},"change_message_id":"76be53c457277de203e81757389207ef0461a275","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"cefafe16_51261044","updated":"2021-11-01 11:55:31.000000000","message":"Hi, would you please have a minute to review this bugfix related to OpenOCD\u0027s server connections.\n\nI understand that the severity of this networking issue may not be apparent because most folks use OpenOCD with \"fast\" targets (read: real physical hardware) where the initialization sequence (probing, loading of images etc.) takes not so much time. So OpenOCD quickly becomes ready to speak to gdb quickly and the issue is masked. \n\nThis issue however becomes very visible to users who have long initialization sequence (e.g. loading of large images to memory). Or to those like me like me who use OpenOCD often with simulated hardware which is many orders of magnitude slower than the physical hardware.\n\nThanks.","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"e881bca152f3f9a79bc2b500a395e1e21427d175","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"11f02321_ccc52a49","updated":"2021-11-11 13:46:58.000000000","message":"I propose a small improvement inspired from real run:\n\n  shutdown command invoked\n  Info : gdb server for \"stm32l5x.cpu\" will be available on port 3333\n  Info : Listening on port 6666 for tcl connections\n  Info : Listening on port 4444 for telnet connections\n  Info : Listening on port 3333 for gdb connections\n","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"},{"author":{"_account_id":1000853,"name":"zapb","display_name":"Marc Schink","email":"dev@zapb.de","username":"zapb"},"change_message_id":"ee653ac514a8f79e04d814a403889e6c67d4311d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b18088d2_72e1bd83","updated":"2021-11-06 10:21:14.000000000","message":"Is there a way to reconstruct this behaviour with an arbitrary target? Otherwise I can only do regression testing :-/ Did you test it with real hardware Tomas?","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"},{"author":{"_account_id":1001667,"name":"Jan Matyas","email":"jan.matyas@codasip.com","username":"JanMatCodasip"},"change_message_id":"4ec4d73b4b1c7d8d366a8d9aebc0fb1858ee8e4a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b7fb8bb0_8a399421","in_reply_to":"ae0f8998_582cab16","updated":"2021-11-10 09:26:34.000000000","message":"\u003e Is there a way to reconstruct this behaviour with an arbitrary target?\n\nYes, the behavior is reproducible with any target.\n\nJust add \"init\" command at the end of your last configuration file, followed by any time consuming operation. You can use \"after \u003cmsec\u003e\", as shown in the commit message. Or any other long operations would do (e.g. multiple load_image and verify_image operations in a loop).\n\nYou can then observe that while the long operations are in progress, TCP connections from gdb can be made but OpenOCD won\u0027t talk to the client until the operations complete, which is the problem I am fixing in this change.\n\nIf I can help any further, please let me know :)","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"b1a22b379e497d1604d89a2b91f2011d303afb34","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ae0f8998_582cab16","in_reply_to":"b18088d2_72e1bd83","updated":"2021-11-06 10:48:35.000000000","message":"I tested with STM32H7A3, where cortex_m and mem_ap targets are created. Then I added rtt server as a tcp service which is started after init. Do you expect some problem?","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"},{"author":{"_account_id":1000863,"name":"Tarek BOCHKATI","email":"tarek.bouchkati@gmail.com","username":"BouchkatiTarek"},"change_message_id":"d38177469411f7c288280446414562e4fd14167c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"68d65c32_89b6cbea","updated":"2021-11-18 09:15:01.000000000","message":"Hi Jan,\n\nThanks for raising this topic !\n\npreviously I have faced this timeout issue between gdb and openocd\ndue to bootrom taking too much time to open the jtag ...\n\nat the time to workarround the issue I have used:\n(gdb) set tcp connect-timeout ...\n\nThus honestly, IMO this patch as-is will just make things worst.\nI\u0027d prefer that openocd will be able to open gdb port when it starts,\nand will able to do the keep_alive thing when it\u0027s needed.\nbecause we don\u0027t know how much time should be between openocd launch and gdb attach\n","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"0371f9027cf82013faf76d33b0e05cf264781277","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ba095226_61c08a9f","updated":"2021-11-18 12:55:56.000000000","message":"I personally share the concept in Andreas msg:\n\n\u003e OpenOCD should be \"fully initialized and ready to talk to the GDB client\" after \"init\",\n\u003e that\u0027s what that command is supposed to do; move from config phase to run phase.\n\nOf course it\u0027s an issue (a bug? a limitation?) that OpenOCD is unable to handle promptly the GDB connection when a command/script is in execution.\nThis happens not only in the init phase (as addressed by this patch), but also during normal execution.\nI work with a multi-CPU SoC, and I have more than one GDB port open by OpenOCD. I get GDB connection timeout if I try to attach GDB to one CPU while the other CPU is erasing flash. This patch will not address this or similar cases.\n\nMy dirty WIP proposal 6703 simply aims at keeping GDB happy during the time from GDB attach to OpenOCD able to handle the connection; either during config or run phases. It needs some cleanup/improvement, but feedback are welcome before I invest other time there.","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"ec489a4fcf17c021a9a8231399705cf5914f0573","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"bbbccf3a_2017ca4c","updated":"2021-11-12 22:56:05.000000000","message":"I remember an odd issue with a windows PC running some crap firewall. Probably Tarek remembers more details (he is younger than me!)\nNormally if you run GDB and try to attach to an OpenOCD that is not started yet or has not opened the TCP port, GDB waits for 10 seconds:\ntime gdb -ex \u0027target remote :8888\u0027 -ex quit\nThe crap firewall triggered a TCP error due to the port not open and caused GDB to return error immediately.\nDelaying the listen() on OpenOCD side can cause GDB to fail connection after 10s timeout or immediately if a crap firewall is present. Potentially GDB has to be re-run few times to catch OpenOCD after this patch.\n\nPersonally I would prefer to let OpenOCD run listen() asap and send some keep_alive() to GDB. I have checked, but GDB requires the initial handshake to be completed before accepting any keep_alive().\nPlus we should start taking care of LLDB too, and I have no idea what it does!\nThis patch is simpler than any rework of keep_alive(), so gets my +1, but I will add in my TODO list to revert it once keep_alive() handles this problem.","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"d5c138ae497c7edeeb762bb1c868888011729192","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"c4cf87d6_d395aaba","updated":"2022-02-01 10:43:55.000000000","message":"I will send out shortly a new version for http://review.openocd.org/6703/\nPlease keep this change on hold, don\u0027t merge it","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"098f33d710ad31a50862170dd408a1845f15baa6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"cb00477b_861544f6","updated":"2021-11-15 19:39:53.000000000","message":"So what to do with this change? Might be better to wait for Antonio\u0027s improvement of keep-alive?","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000005,"name":"Andreas Fritiofson","email":"andreas.fritiofson@gmail.com","username":"Nattgris"},"change_message_id":"935e84adf0ff18b3eff7e8b43adcc9675f89493a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a6bee250_2b026ea9","updated":"2021-11-15 10:39:09.000000000","message":"What I don\u0027t really understand is why everything including the GDB server isn\u0027t up and running after \"init\". OpenOCD should be \"fully initialized and ready to talk to the GDB client\" after \"init\", that\u0027s what that command is supposed to do; move from config phase to run phase.\n\nConsider what happens if you do the same sequence, but move everything after init (i.e. the long-running part) from the config file to a telnet/rpc session which is started as soon as possible. Do you get the same effect with a timeout in GDB? I suspect not, because that would mean some operation is not servicing the keep_alive() properly.\n\nIMO the two ways of entering commands should be equivalent. Unfortunately I think they are not, and maybe that\u0027s the problem that needs solving?","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"83828c4d84169fc7e6ff966c4aa7498aa1d2cd8e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"95997500_6afb63c9","updated":"2021-11-16 00:53:38.000000000","message":"please check http://review.openocd.org/6703","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"c1d493b6ab0c60917ad6af59bbcdf2bc7d01c5d4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"30b627d1_1f4b9330","in_reply_to":"22d8c9e9_9dd99fdf","updated":"2021-11-15 17:59:07.000000000","message":"No, there is no need to move all this stuff.\nI have checked GDB code. It expects the TCP connection to be accepted immediately (actually the TCP stack allows 10 seconds grace timeout), then GDB sends the first remote command made by the string \"+$qSupported: ...\". The reply from OpenOCD has to arrive within the usual 2 seconds, otherwise GDB sends the string again 3 time and then timeouts.\n\nYou can check this by opening a port with netcat in one console and connect with GDB from another console:\nnc -l -v 1234\ngdb -ex \u0027target remote :1234\u0027\n\nAfter GDB has sent the string \"+$qSupported: ...\" it already accepts the keep-alive to avoid the timeout.\nYou can try by launching GDB first and within 10 seconds (TCP timeout) open and send 1s keepalives:\ngdb -ex \u0027target remote :1234\u0027\nwhile sleep 1;do echo \u0027\u0027;done | nc -l -v 1234\nYou will get the first \"+$qSupported: ...\", then GDB accepts the keepalive and waits forever for the reply.\n\nSo the trick is to extend keep_alive() to let it check if there is one incoming connection and accept it. Then sending the keepalive is already implemented.\nThe string sent by GDB has to be read and managed later, when OpenOCD can do it.\n\nApparently it works with LLDB too, but I have not checked the code.","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"1a87c9c6a5084cf80d507645a83f5d20b337d225","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"55c4746a_2bea71ad","in_reply_to":"30b627d1_1f4b9330","updated":"2021-11-15 18:59:47.000000000","message":"I\u0027ll try to implement it. Describing it is getting harder than coding it ....","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"5b3b73617a72bdcabe7b63478776fa77cf35dc7a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"e7958fde_9a1e947d","in_reply_to":"52703cd9_063fb68a","updated":"2021-11-15 13:51:16.000000000","message":"OpenOCD commands lock the execution, are not reentrant. We cannot easily convert OpenOCD in a multi-thread application. So if one command takes long, everything else is waiting. That\u0027s it!\nkeep_alive() only sends a small empty packet to GDB that would otherwise timeout if it see no activity on the remote connections.\nMy proposal is to extend a little the scope of keep_alive(), without going to full multithread","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"098f33d710ad31a50862170dd408a1845f15baa6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"34ece3bd_c7849abc","in_reply_to":"55c4746a_2bea71ad","updated":"2021-11-15 19:39:53.000000000","message":"\u003e After GDB has sent the string \"+$qSupported: ...\" it already accepts the keep-alive to avoid the timeout.\n\nI\u0027m surprised. I thought we have to run whole handshake. This looks promising....","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1001667,"name":"Jan Matyas","email":"jan.matyas@codasip.com","username":"JanMatCodasip"},"change_message_id":"09d0cd6e6633e6a5fc421886e0980f086481ab60","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8f56890d_ede24bd9","in_reply_to":"68d65c32_89b6cbea","updated":"2021-11-18 11:17:32.000000000","message":"Hi Tarek, thank you for replying.\n\n\u003e IMO this patch as-is will just make things worst. I\u0027d prefer that openocd will be able to open gdb port when it starts, and will able to do the keep_alive thing when it\u0027s needed. Because we don\u0027t know how much time should be between openocd launch and gdb attach.\n\nI still believe this change is an improvement (my viewpoint explained below) but am definitely happy to explore other approaches.\n\nI will be able look at Antonio\u0027s proposal in few days (http://review.openocd.org/6703).\n\n\n\nJust to explain my viewpoint, my rationale behind this change was:\n\n1) If GDB is launched manually by the user, the user is able to tell from the log when OpenOCD is ready to accept GDB connection. Even if the user tries to connect with GDB too early, he will get notified about that and can retry the operation later.\n\n2) If GDB is launched by another third-party program in an automated fashion, the software can poll (repeatedly try to connect to) the OpenOCD\u0027s gdb port until it succeeds, meaning that OpenOCD is ready.\n\nThe option 2) is not really possible right now, because the gdb connection can be established right now even though OpenOCD is not yet ready to talk back. So that is the situation I tried to improve in this merge request.\n\n\nAnyway, let\u0027s explore other options, too :)","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"f1a9bf12ca5055c31ec53fc0fea57a7be15848f2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b9fc8225_fa537313","in_reply_to":"a6bee250_2b026ea9","updated":"2021-11-15 10:50:55.000000000","message":"Andreas, the telnet server get up and running immediately because the telnet client can wait indefinitely, it\u0027s not interested to the server\u0027s reply.\nGDB, after connect(), starts immediately some handshaking, target type, num and type of registers, and so on. OpenOCD handles new connection in server_loop(), but this is stopped by any command in execution.\nRun in a telnet \"sleep 10000000\" and while the sleep is on-going try to connect with GDB; timeout after 10 seconds.\nMy proposal to extend the keep_alive() is because this is the only underlining execution during a long command. The keep_alive() could manage the initial GDB handshake, then send the keep-alive to avoid the timeout. But this is a major rework.","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"d37ea9ff88a092a8a0ad2a1f725a12176820527a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"52703cd9_063fb68a","in_reply_to":"b9fc8225_fa537313","updated":"2021-11-15 12:31:02.000000000","message":"\u003e OpenOCD handles new connection in server_loop(), but this is stopped by any command in execution.\n\nEven worse: all socket processing is dead during tcl command execution, no matter if the command calls keep_alive() or not! Run a long flash write_image in one telnet and try to write anything to the second telnet. No char is echoed until write_image is done.\nDamn, what is keep_alive() for? Doing nothing? And issue error messages if not called frequently enough?","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1001667,"name":"Jan Matyas","email":"jan.matyas@codasip.com","username":"JanMatCodasip"},"change_message_id":"2873ccea395425486ab2141bd1288a5988e2a6d7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b5f836c9_7cac9c39","in_reply_to":"bbbccf3a_2017ca4c","updated":"2021-11-15 08:36:41.000000000","message":"\u003e Potentially GDB has to be re-run few times to catch OpenOCD after this patch.\n\nThat is correct, and expected. The same problem is present in the current OpenOCD but is somewhat masked: In case the initialization (e.g. loading of program binary) exceeds the GDB timeout, the user still needs to re-run/re-connect GDB multiple times.\n\n\n\n\u003e Personally I would prefer to let OpenOCD run listen() asap and send some keep_alive() to GDB. I have checked, but GDB requires the initial handshake to be completed before accepting any keep_alive().\n\nI\u0027m afraid that listen() is not sufficient - this would be more complex. The incoming connection need to be accept()\u0027ed and then handled properly. If wish to be able to do all this work before server_loop(), that sounds like a bigger piece of work than it may seem (major refactor of how network connections are handled in OpenOCD?).","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"3b59e6cd7587dba29157afe86b0218de8006216c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"22d8c9e9_9dd99fdf","in_reply_to":"e7958fde_9a1e947d","updated":"2021-11-15 17:17:55.000000000","message":"\u003e My proposal is to extend a little the scope of keep_alive(), without going to full multithread\n\nA little? Initial GDB handshake includes calling gdb-start event, probing flash to get memory map. keep_alive() would have to read incoming data from sockets not only accept incoming connection - seems me almost all content of server_loop() would move to keep_alive().\n\nIn this case the telnet server can easily run line editor and wait before starting new command if we want to prevent full multithreading.","commit_id":"c11eb100fdb2b38a82bdfc85a9356b8924a0ddaa"}],"src/server/server.c":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"e881bca152f3f9a79bc2b500a395e1e21427d175","unresolved":true,"context_lines":[{"line_number":485,"context_line":"#endif"},{"line_number":486,"context_line":""},{"line_number":487,"context_line":"\t/* Start listening for all services */"},{"line_number":488,"context_line":"\tif (start_listen() !\u003d ERROR_OK)"},{"line_number":489,"context_line":"\t\tshutdown_openocd \u003d SHUTDOWN_WITH_ERROR_CODE;"},{"line_number":490,"context_line":""},{"line_number":491,"context_line":"\twhile (shutdown_openocd \u003d\u003d CONTINUE_MAIN_LOOP) {"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"53578a95_ae6cbc0b","line":488,"updated":"2021-11-11 13:46:58.000000000","message":"We may run start_listen() only if shutdown_openocd \u003d\u003d CONTINUE_MAIN_LOOP\notherwise listening is started even in case that an init script calls shutdown","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"},{"author":{"_account_id":1001667,"name":"Jan Matyas","email":"jan.matyas@codasip.com","username":"JanMatCodasip"},"change_message_id":"12a857789a76a3b8cce2ecc7baf81472f0d70e1e","unresolved":true,"context_lines":[{"line_number":485,"context_line":"#endif"},{"line_number":486,"context_line":""},{"line_number":487,"context_line":"\t/* Start listening for all services */"},{"line_number":488,"context_line":"\tif (start_listen() !\u003d ERROR_OK)"},{"line_number":489,"context_line":"\t\tshutdown_openocd \u003d SHUTDOWN_WITH_ERROR_CODE;"},{"line_number":490,"context_line":""},{"line_number":491,"context_line":"\twhile (shutdown_openocd \u003d\u003d CONTINUE_MAIN_LOOP) {"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"6d0cc5b5_12f60074","line":488,"in_reply_to":"53578a95_ae6cbc0b","updated":"2021-11-11 15:27:59.000000000","message":"Thanks, good point. I have updated the code accordingly.\n\nWhat were your steps to reproduce?\n\nI reproduced the situation by sending a signal to OpenOCD (e.g. Ctrl-C) during a long-running operation executed in a script after init (e.g. \"after 60000\", as shown in the commit message).","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"b9c9590e19b7bc120fd1d66dee6a280ef6c953b1","unresolved":false,"context_lines":[{"line_number":485,"context_line":"#endif"},{"line_number":486,"context_line":""},{"line_number":487,"context_line":"\t/* Start listening for all services */"},{"line_number":488,"context_line":"\tif (start_listen() !\u003d ERROR_OK)"},{"line_number":489,"context_line":"\t\tshutdown_openocd \u003d SHUTDOWN_WITH_ERROR_CODE;"},{"line_number":490,"context_line":""},{"line_number":491,"context_line":"\twhile (shutdown_openocd \u003d\u003d CONTINUE_MAIN_LOOP) {"}],"source_content_type":"text/x-csrc","patch_set":2,"id":"6bf34b61_04729a42","line":488,"in_reply_to":"6d0cc5b5_12f60074","updated":"2021-11-11 18:38:55.000000000","message":"Just noticed it after early shutdown in tested https://review.openocd.org/c/openocd/+/6546","commit_id":"82ba65b0d3063a903731b9b461ac03a848c65809"}]}