semihosting to Adapter Output requires new line

[perlindgren]

semihosting can be enabled by:

 "postLaunchCommands": [
                "monitor arm semihosting enable"
  ],

The Adapter Output window display the openocd output. It works fine as long as a newline character is printed (at the end). If just printing single characters (without trailing newline) then the Adapter Output window is not updated. If I run the same program outside of vscode (openocd + gdb), the openocd console gets updated on each character sent, so it seems to be a vscode/cortex-debug issue. (Besides that minor issue, semihosting works well for me in vscode.)

Best regards
Per

[Marus]

I'll take a peak at this - although I'm not sure if I'll be able to work around this. From what I recall the VC runtime won't actually give my plugin the output from the executable until it gets the newline (or is explicitly flushed) - but there may be some work around - will see what I can do.

[noppej]

stdout is buffered by default, so it shouldn't flush automatically. fflush(stdout) will force a character (or incomplete block) to be written out of the buffer. Alternatively, modify default buffering with setbuf. A Google search on this topic should provide good examples :-)

[ondono]

I know it's an old-ish issue, but I'm having the same problem. Buffering doesn't seem to be the issue here.

stdout is buffered by default, so it shouldn't flush automatically. fflush(stdout) will force a character (or incomplete block) to be written out of the buffer. Alternatively, modify default buffering with setbuf. A Google search on this topic should provide good examples :-)

If I start openocd and gdb from terminals, even if I use the vscode ones, everything works fine. Lines are printed into the openocd output without a newline (I've disabled buffering in code).

If I setup the same configuration via the extension, It won't work unless a newline is present.

I don't know enough about how the extension works to even make theories, but my uninformed guess is that since a newline is not present on the openocd output console, the extension is not processing it.

[haneefdm]

Guesswork from my part and what I know.

When you use a terminal (yes, even the VSCode ones), things may be buffered differently. Terminals buffer up to a newline unless explicitly flushed. Even the C-runtime works a bit differently. It is not the same as buffering on a pipe or socket or file. And, since there is a chain of things, your FW, openocd, this-extension, etc. all have to have do minimal buffering.

Node.js (which VSCode and this extension uses) does buffer incoming data but lets the waiting app know when additional data is available and newline is a trigger. Chances are, no newline, no trigger unless the buffer is about to overflow.

Please note that if OpenOCD output is not being read by VSCode and/or gdb then nothing would have worked.

[haneefdm]

We have moved to a new Terminal (gdb-server) and handle newlines and linefeeds much better than the VSCode Output windows. Also ANSI sequences for coloring, etc. On our part, there is no buffering of output but it could still be there upstream in other programs.