You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@mynewt.apache.org by "Simon Ratner (JIRA)" <ji...@apache.org> on 2017/03/03 10:49:45 UTC

[jira] [Commented] (MYNEWT-643) ctrl-c on windows during 'newt debug' kills jtag software

    [ https://issues.apache.org/jira/browse/MYNEWT-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15894126#comment-15894126 ] 

Simon Ratner commented on MYNEWT-643:
-------------------------------------

Windows console apps don't really have a concept of signals. The console generates special "events" for ctrl-c and ctrl-break, which apps can handle.

When bash runs a Windows process, it just pipes stdio and does not emulate the Windows Console API (because that is impossible for a third-party app on Windows). When you press ctrl-c, bash kills the process, but the app never sees the console events it is expecting. 

This has a description: http://stackoverflow.com/questions/11757643/cygwin-ctrl-c-signal-interrupts-not-working-properly-jvm-shutdown-hooks-not

So:

- msys2/cygwin executable running in bash gets signal handling from the runtime (e.g. msys2 gdb correctly handles ctrl-c, when launched from bash),
- native Windows executable running in native console gets the console events (e.g. native gdb correctly handles ctrl-c, when launched from cmd.exe),
- native Windows executable running in bash gets killed by any signal, without an opportunity to handle it.

In my setup (and, likely, yours), openocd and arm-none-eabi-gdb are native Windows executables, so what you are trying to do can't be done with just a bash script.

However, I've been running this successfully by launching the native Windows apps in their own cmd.exe process. You get two extra windows pop up, but they do close once you are done so it isn't a huge deal.

Here is my patch:
{code:none}
diff --git a/hw/scripts/openocd.sh b/hw/scripts/openocd.sh
index 8caf3eb..cb98cf5 100644
--- a/hw/scripts/openocd.sh
+++ b/hw/scripts/openocd.sh
@@ -77,9 +77,7 @@ openocd_debug () {
        #
        # Block Ctrl-C from getting passed to openocd.
        #
-       set -m
-       openocd $CFG -f $OCD_CMD_FILE -c init -c halt &
-       set +m
+       cmd /C "start cmd /C openocd $CFG -f $OCD_CMD_FILE -c init -c halt"

        GDB_CMD_FILE=.gdb_cmds

@@ -87,15 +85,15 @@ openocd_debug () {
        if [ ! -z "$RESET" ]; then
            echo "mon reset halt" >> $GDB_CMD_FILE
        fi
-       arm-none-eabi-gdb -x $GDB_CMD_FILE $FILE_NAME
-       rm $GDB_CMD_FILE
+       cmd /C "start cmd /C arm-none-eabi-gdb -x $GDB_CMD_FILE $FILE_NAME"
+       #rm $GDB_CMD_FILE
     else
        # No GDB, wait for openocd to exit
        openocd $CFG -f $OCD_CMD_FILE -c init -c halt
        return $?
     fi

-    rm $OCD_CMD_FILE
+    #rm $OCD_CMD_FILE
     return 0
 }

{code}

Yes, those do look silly ;) That's because "start" is a cmd built-in. If you prefer the cmd windows to hang around after you are done (for example, to see error output after process exit), change the inner "start cmd /C" to "start cmd /K".

> ctrl-c on windows during 'newt debug' kills jtag software
> ---------------------------------------------------------
>
>                 Key: MYNEWT-643
>                 URL: https://issues.apache.org/jira/browse/MYNEWT-643
>             Project: Mynewt
>          Issue Type: Bug
>    Affects Versions: v1_0_0_rel
>            Reporter: Marko Kiiskila
>
> At least when using http://win-bash.sourceforge.net/ as the bash.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)