Is there a way to control the Fujitsu Softune debugger with an other application(e.g. Eclipse)? I think about sending the command mentioned in the documentation of Softune and parse the output, but also other approaches are welcome.
There is pluging for eclipse; file name is "FujitsuF2MC16_1.0.1.jar", look for it on this page:
http://www.mikrocontroller.net/topic/70413
Complile en debug in eclipse.
Hope this helps.
What do you mean by controlling the Fujitsu Softune debugger?
If what you want to do is to start a debugging session with your freshly-compiled .abs file, you can do the following.
In the Eclipse environment add a button or shortcut to call the make utility to make a debug:. Your makefile would have an entry like:
debug: $(make_vars)
# start debugger
make -f$(make_vars) -f$(make_dir)/$(cfg) cfg="$(cfg)" debug_session
In the make entry for debug_session you put something like:
echo UPDATING SOFTUNE-3 PROJECT FOR DEBUGGING;\
$(subst \,/,$(DIR_SOFTUNE_WORKBENCH))/bin/Fs907s.exe softune/E7x_proj.wsp 2>/dev/null;
I hope this was useful.
Related
Ubuntu. vscode 1.62.1. go1.17.3. vscode go extension v0.29.0. delve v1.7.1.
I'm new to vscode and Go. I have many years of experience debugging Java apps in Eclipse.
I've constructed a small multi-module Go app. I can set a breakpoint in main and other functions in other modules. Inside main.go, I select "Start Debugging".
It starts the application, and I can tell it's working from the console, and that the REST endpoint responds with my dummy response.
However, it will NOT stop at breakpoints. As soon as I start the session, the red breakpoint markers suddenly become hollow, and hovering on one of them shows a message "Could not find file ...", which prints the full path to the source file in question.
When I start it, it shows the following in the console:
Starting: /home/.../go/bin/dlv-dap dap --check-go-version=false --listen=127.0.0.1:43347 --log-dest=3 from /home/.../...
DAP server listening at: 127.0.0.1:43347
I haven't modified the launch.json (I hope someday a friendlier interface to editing launch configurations is provided).
What else could I be doing wrong?
Update:
This is a screenshot showing main.go just before I press F5 (Start Debugging):
Notice that I have a breakpoint on the print statement, on the first line of main.
This is what I see after I press F5:
Notice that it printed "At start of main" in the console. It didn't stop at the breakpoint. Also notice message in tooltip when hovering over the breakpoint.
Update:
This is a view of my directory structure:
First, just make sure you have initiated your project with go mod init voltagems: that would explain the import "voltagems/xxx", but also helps delve to find your main.go file at debug time.
You should have go.mod and go.sum files beside main.go.
Second, check your go env output, making sure GOPATH and GOROOT are set to default paths.
The OP David M. Karr adds in the comments:
I did run "go mod init" when I first created the project, but I realized that I didn't like the root module name, so I changed it to "voltagems"
I believe you can edit directly go.mod first line, and make sure it says:
module voltagems
Then go mod verify + go mod tidy
Finally, go build .. Restart your VSCode (or the command Reload Window), and see if the issue persists.
The OP David M. Karr points out to a root cause:
There are symbolic links in my project path.
There is a "substitutePath" configuration in VSCode-Go that is used to map to absolute paths.
You can see this parameter mentioned in Debugging with Legacy Debug Adapter
substitutePath
Path mappings to apply to get from a path in the editor to a path in the compiled program (default: []).
That comes from issue 622 "debug: breakpoints don't work when working with symlink".
And commit 93f32bb
src/debugAdapter: add substitutePath config for debugging
This change adds a new configuration option to both launch and
attach requests.
substituePath takes an array that maps from string to string that is used to translate paths passed to the debugger and then
back to the client.
This allows users to translate their symlinked directories to the
files that were actually used to build the binary.
In addition this can also be used for remote debugging, and when the location of the files has moved since the program was built.
Example: you need a from and to key:
"substitutePath": [
{
"from": "/symlink/path/dir/on/local/machine",
"to": "/absolute/path/dir/on/local/machine",
},
At $DAYJOB, I am trying to implement reproducible builds to make debugging released software where we no longer have the full debug versions on our build servers easier, using the tips from reproducible-builds.org.
Using the -ffile-prefix-map=/path/to/build=src option in GCC to avoid leaking internal file paths does help making some error messages cleaner, but does produce problems when using GDB. I am in /path/to/build/some/binary/ and hitting a breakpoint in /path/to/build/lib/cclib/:
Breakpoint 1, [...]
at src/lib/cclib/eventloop.cc:154
154 src/lib/cclib/eventloop.cc: No such file or directory.
(gdb)
As a workaround, I can symlink src to the root of the build tree, but is there a better way to make sure gdb understands the mapping?
GDB has a few configuration commands to direct the way it searches for source code. In your case, where you have a tree of source code and you need to change a path prefix, set substitute-path DWARF-compilation-dir actual-dir should be all you need to do.
set substitute-path src /path/to/build
CLion is a powerful multi-platform IDE that allows to run and debug C++ applications.
I tried to use it with an AzerothCore core project.
It is smart enough to detect all the processes:
Mostly I'm interested in running the worldserver.
However when I try to run or debug it, it correctly compile and runs but it will look for the worldserver.conf.dist configuration file in the directory /usr/local/etc/, giving error because that file is not there.
I would like to manually specify the path of such configuration file, as well as passing other CMake parameters.
I made it work by opening File -> Settings and looking for "CMake" under "Build, Execution, Deployment".
From that window I could pass my CMake options, which in my case where:
-G "Unix Makefiles" -DTOOLS=0 -DSCRIPTS=static -DCMAKE_C_FLAGS="-Werror" -DCMAKE_CXX_FLAGS="-Werror" -DCMAKE_INSTALL_PREFIX=/path/to/the/main/server/dir
The /path/to/the/main/server/dir is where my etc, data, etc... folders are and the worldserver.config.dist is inside this etc folder. So doing this everything worked fine.
I also changed the "Build options" to better use my processor, passing -j 10.
For macOS users, you'll probably need to add these CMake options as well:
-DMYSQL_ADD_INCLUDE_PATH=/usr/local/include
-DMYSQL_LIBRARY=/usr/local/lib/libmysqlclient.dylib
-DREADLINE_INCLUDE_DIR=/usr/local/opt/readline/include
-DREADLINE_LIBRARY=/usr/local/opt/readline/lib/libreadline.dylib
-DOPENSSL_INCLUDE_DIR=/usr/local/opt/openssl/include
-DOPENSSL_SSL_LIBRARIES=/usr/local/opt/openssl/lib/libssl.dylib
-DOPENSSL_CRYPTO_LIBRARIES=/usr/local/opt/openssl/lib/libcrypto.dylib
The Julia docs are pretty clear on how to enable debugging messages from #debug macros, i.e. run export JULIA_DEBUG=mymodule or export JULIA_DEBUG=all on the command line before starting Julia. However, is there an easy way to enable debugging from within the Juno, or, more generally, while Julia is running?
I tried fiddling with Base.CoreLogging.disable_logging , Base.CoreLogging.BelowMinLevel and Base.CoreLogging._min_enabled_level without success.
I know I can set env variables for Julia in the Juno settings. But that's kind of annoying to work with as it requires restarting Julia. I really want to have the following workflow while working interactively:
Enter a line in the REPL
Stumble upon a bug from your own code that you didn't see coming.
Enable debugging.
Run that line again.
See the debug logs.
Fix your code.
Disable debug logging again.
Which I think is nicer than the common practice of commenting and un-commenting printf everywhere.
Enable #debug everywhere (this will only affect code loaded after running the following expression):
julia>ENV["JULIA_DEBUG"] = "all"
Enable #debug in file foo.jl (according to docs, haven't tested this):
julia>ENV["JULIA_DEBUG"] = "foo"
Disable #debug:
ENV["JULIA_DEBUG"] = ""
important note: macros are evaluated when code is loaded. So the tricks above will only have effect on code that is loaded after changing the value of JULIA_DEBUG. So after setting it to e.g. all, nothing will have changed. Reload the modules you want to #debug.
To enable #debug messages logging in your julia script:
# ... script ...
ENV["JULIA_DEBUG"]="all"
# debug messages are now enabled.
# ... Rest of the script...
The addition of ENV["JULIA_DEBUG"]="all" will enable #debug messages when running the script in Juno or running it with Julia from your terminal.
After a few mistake builds with the Release configuration pushing stuff to other environments I'd like to have a warning or prompt of some sort to stop me from doing such madness if I don't really want to.
Is there a way to make this happen? :)
The simplest way that I can see of doing this is to leverage the Build Events dialog in the Project Settings.
First add a file called usermessage.vbs to the solution. It should contain the following:
a = MsgBox("Continue with Debug Build",1,"Build Configuration Warning")
if a=1 then WScript.Quit(0) Else WScript.Quit(1) End If
This will present an OK/Cancel dialog which returns an error unless you click OK.
Add this code to the Pre-build event command line:
if $(ConfigurationName) == Debug WSCRIPT.EXE "$(SolutionDir)usermessage.vbs"
This will run the script if you build in debug configuration.
The script will error and the build will halt unless you click OK in the dialog.