How can I set a C/C++ memory watchpoint in vscode? - visual-studio-code

In gdb I can type watch &variable, then continue and gdb will break whenever something writes to that address.
I am using vscode to debug and want to do the same thing (This is different from the watch window, which will only show variable values after a breakpoint has been hit). Is it possible?
I can manually add a breakpoint by clicking the '+' and enter &variable but it never becomes active and says the module has yet to be loaded. I've tried manually entering -exec watch &variable in the debugger console window, but after continuing execution with the play button it hangs (vscode thinks the program is running again but it's not).
There are some github issues for this but they're closed without reason:
https://github.com/microsoft/vscode/issues/55931
https://github.com/microsoft/vscode/issues/47117
https://github.com/microsoft/vscode-debugadapter-node/issues/38

I had luck watching on an address. For example, if my target variable was at address 0xb79b90, I would execute -exec watch *0xb79b90 in the gdb terminal. Then I'd double check it was added as a hardware watchpoint with -exec info watch.
After continuing execution, the debugger would halt with an exception once the watchpoint is hit. vscode would display the line after the value was changed. I could then continue from there if necessary.

Related

Similar Neovim mappings--one works, one does not work

Context
Creating remappings to exit TERMINAL mode and enter NORMAL mode within neovim (ie. <C-\><C-N>).
I'm getting no-op behavior (ie. terminal stays in TERMINAL mode and simply ouputs , -- mapleader) when creating a new mapping as follows (in init.lua):
keymap.set("t", "<leader><Esc>", "<C-\\><C-N>")
Shell is zsh and I've set bindkey -v in .zshrc. Terminal application is iterm2.
When I set the following mapping:
keymap.set("t", "<leader>nn", "<C-\\><C-N>")
The expected behavior happens (ie. terminal exits TERMINAL mode and enter NORMAL mode).
Not sure how/where the first mapping is getting interrupted to not exit TERMINAL mode.
Question
Why is the first mentioned mapping not working, which the second mentioned mapping is working?
Effort
Looked on other posts and they all indicate there should be no problem with the first mapping.

Weird CMD - VSCode behavior

yesterday I had SumatraPDF and VisualStudioCode with latex-workshop working with forward and reverse-search. Today the reverse-search didn't work any more. With a simple bat file I tried to show the commandline arguments.
echo %*
pause
They seemed correct and when I copied the command and paste it into a new cmd it works. To do further testing I tried to direct command and run it.
"C:\....\Code.exe" -g "%1:%2"
pause
Visual Studio Code responds: bad option -g
In SumatraPDF I set cmd as command.
Now the behavior is that I have two cmd windows. With the cmd directly opened the VSC open's the file. With the cmd launched indirect I got the error message.
I have tried resetting the environment variables, changing the current working directory, and checking the code page currently in use.
How can it be that cmd behaves differently with seemingly the same environment? And what can I do to make a cmd started from an application work like a cmd started by windows?
Update: It appears there were a couple of recent security changes in the way VSCODE.exe is allowed to interact with the command line (especially affecting LaTeX-workshop users) so for recent changes twice this year see the discussion at https://forum.sumatrapdfreader.org/t/inverse-search-not-performed-for-vs-code-exe/4486/27
Within SumatraPDF the reverse syntex command for %1 is replaced by %f for file and (l)L for line
It is triggered by a double click near the line of interest and if the synctex index file was compiled correctly by PdfLaTeX (or similar) it will include the tex %f(ilename) and the nearest %l(ine) reference to the point where double clicked.
Thus your tex syctex enhanced "reverse search" call out of SumatraPDF should historically be
"C:\...path to...\Code.exe" -g "%f:%l"
that's Lower L not 1
Avoid using any depreciated -inverse-search parameter from a LaTeX editor just add it once into SumatraPDF-settings.txt and then it's not disturbed by repeated assignments when running your -forward-search.
It will NOT work if the file.synctex or file.synctex.gz is corrupt by a bad PDF compilation.
HOWEVER It seem Microsoft have added the requirement to add a CLI.js handler and requires another switch setting after that ! (see link to discussion in Update above)
For a small test file download https://github.com/GitHubRulesOK/MyNotes/raw/master/AppNotes/SumatraPDF/LATeX%20and%20Reverse-Search.zip unpack and open sync.pdf in SumatraPDF to test that double click on page opens sync.tex in the editor
If the message is cannot start ... then the command line is not configured correctly. A rough test for a bad synctex is to see what happens if the call is changed by adding cmd /k echo to the start, since that will confirm the reverse command. Here I wrote "wrong" as the path to code.exe, once corrected I can remove cmd /k echo.
For some other systems where the reverse might change
see https://github.com/sumatrapdfreader/sumatrapdf/issues/1197#
However there should be no interference in a valid VsCode call.

Why is Simics bt / stack-trace command returning "No current debug object"?

I run
C:\Users\io\simics-projects\my-simics-project-1>simics.bat targets\qsp-x86\firststeps.simics
I then run "run" and let the system proceed all the way to the clear linux shell prompt. I then run "stop" to pause the simulation. But I get an error of "No current debug object". I would think a simple stack trace would simply follow the %rbp frame pointers backwards on the stack and display what's there. Why isn't it?
simics> run
Autologin as "simics" was done on "board.mb.sb.com[0] - serial console".
running> stop
simics> bt
No current debug object
(I also just noticed the same happens when I just try "step-out". Which again, I would think would simply step through instructions until after it hits a "ret"...)
I think the debugger is not enabled. To do so, the command is
enable-debugger

VSCode exit code 9009 popup when manually exit the terminal

Every time I stop the Python debugger and exit the terminal, I receive a popup notification in the lower-right of VSCode:
Because I stop the debugger and exit the terminal dozens of times per day, this is a nuisance. I could just ignore it (there is only ever one opened - and it doesn't stop anything from working), but then it's always there sitting on top of code I want to see.
IS THERE some setting (perhaps in settings.json) that would disable this message?
Failing that, is there some way to auto-close it on a 1-sec timer?
Add this to your settings.json: "terminal.integrated.showExitAlert": false
Option to disable alert The terminal process terminated with exit code

VSCode task in WSL environment, terminal keeps exiting when trying to run shell script

NOTE
I've had to remove like two chunks of this post because stack overflow kept interpreting it as code when it isn't and it wouldn't let me post, I'll just make a screenshot of what the post is supposed to look like and post it here. Read this instead.
Summary
I was finally trying to learn how to use VSCode tasks and so I copied the first task example from here and created a shell script at scripts/test.sh which contains simply "echo foo". I also commented out the windows alternative script because I exclusively use WSL/Bash. Whenever I run the task I receive a "The terminal process terminated with exit code: 1" error message, which is no help whatsoever.
Testing
I ran various tests and I have no idea why this isn't working.
Proving The Task Is In The Correct Directory & In WSL
First I thought maybe the task isn't running in WSL or that the directories are out of sync, so I changed the commands to see what happens.
First, I changed it to:
"command": "pwd",
and the output was "/mnt/f/.../.../tmp/tmp.1BitOIA78E" (... are for some arbitrary path) so clearly I concluded I was running on WSL and in the right path.
Proving the Script is Executeable
Next I thought, maybe the script I'm trying to run isn't executable or something to that affect, so I changed the command to:
"command": "stat ./scripts/test.sh",
and I got the following output which shows, the file exists, it's executeable & can be accessed through "./scripts/test.sh" from whatever directory the Task is set to on construction
I run the task by typing ctrl-shift-P to open the menu, select "run tasks" and then select 'My First Task'.
Note: I don't think this is a settings problem. There're no workspace settings setup (because this is just me testing) & just in case, you can find my current user settings here which I updated immediately before posting this.
Expectations
What I'd like is either:
Someone to tell me how I can access the stderr and stdout log of the shell upon startup so I can get some actually helpful information as to why this is happening.
Someone to tell me why I can run a script perfectly fine outside of a task, but within a task it completely fails.
Whats also of note is that the script isn't the problem here. Leaving it completely blank, doesn't stop the terminal from straight up crashing.