I'm trying to debug a program written using Go inside eclipse. I can set and hit breakpoints pretty consistently, but I cannot view the contents of my variables. When I start debugging the program, I always get the following error on my console.
warning: File "/usr/local/go/src/pkg/runtime/runtime-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
line to your configuration file "/home/johnlawrie/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/johnlawrie/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
Thinking that the problem might be due to the error message, I put the entry into my .gdbinit file as instructed. However, I get the same message every time I run as if I did nothing at all. This is the contents of my /home/johnlawrie/.gdbinit file
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
Any ideas what I need to do to make this change take effect? I have tried logged off and back in.
Thanks,
John Lawrie
It did learn what was happening. When gdb is started from Eclipse/CDT, it is started with option -nx, which means it doesn't load .gdbinit in the home directory.
I was able to get this to work by creating a .gdbinit file as a peer to the src, bin, and pkg directories in my workspace and adding the following line to it
set auto-load safe-path /usr/local/go/
It should be add-auto-load-safe-path /usr/local/go/src/pkg/, not the path to the script.
Also keep in mind that gdb doesn't really work with Go, specially v1.3.
From http://golang.org/doc/gdb:
GDB does not understand Go programs well. The stack management,
threading, and runtime contain aspects that differ enough from the
execution model GDB expects that they can confuse the debugger, even
when the program is compiled with gccgo. As a consequence, although
GDB can be useful in some situations, it is not a reliable debugger
for Go programs, particularly heavily concurrent ones. Moreover, it is
not a priority for the Go project to address these issues, which are
difficult. In short, the instructions below should be taken only as a
guide to how to use GDB when it works, not as a guarantee of success.
Related
I'm in the process of trying to write a VSCode extension to support basic SNES application development. I already have a basic grammar definition and build task, so I have syntax highlighting, and am able to build my project with Ctrl+Shift+B using the bass v14 assembler, but now I'm trying to figure out how to launch the project using launch.json. I've already worked through the official docs and played around with the mock debugger project, but I can't seem to figure out how to adapt it for my extension. To start, I'm using the bsnes-plus emulator as my debugger. There isn't really any command-line or IPC interface that will actually allow me to implement a proper debug adapter, so all I really want to do is to run the program and pass it my output file to launch. For the time being, I'm assuming that bsnes-plus.exe is located in my $PATH, but eventually I'll try and figure out the best practices for external executable dependencies for an extension.
So here are my current questions:
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
At one point, I was able to get the launch command to open bsnes-plus, but not load the game, and when I closed it, VSCode complained that the debugger terminated unexpectedly and immediately re-opened bsnes-plus. How do I avoid this? Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
Is the "program" field of launch.json my compiled application, or is it bsnes-plus.exe?
This is entirely up to the debug extension. It's just passed through to the debug adapter. It usually corresponds to the specific app/script being debugged though, not the runtime that's running it, so I would suggest it should be your compiled application.
If "program" is my application, where do I specify bsnes-plus.exe? Or vice versa.
You can put it any other field. In Dart, we have a dartPath field that can be passed through to the debug adapter. It's usually populated silently by the DebugConfigurationProvider.resolveDebugConfig though (we detect the SDK by searching PATH) so the user never needs to add it.
Is there a way to specify my own project-level variables, e.g. $OUTPUT so that I don't have to hard-code the output filename into both the build task and the launch task?
You can't make your own variables, but using resolveDebugConfig you can manipulate the launch config yourself before it's passed to the debug adapter, which probably allows you to do what you need here (eg. you could do a string replace on program - or you could even just add it if it's not set, allowing a launch.json-less launch too).
Do I need to write a debug adapter even though it's not going to actually do anything other than launch the application, just so I can tell VSCode that it exited cleanly?
I'm not sure what happened here without more details, but having a debug adapter probably makes the most sense - for example if you want to make the Stop/Restart buttons work on the toolbar, you'd probably want a debug adapter that can terminate and/or restart the process.
An "Errors exist in the active configuration of project X. Proceed with launch?" dialog appears while debugging code in Eclipse. Hitting the "Proceed" button results in successful debugging. There are no apparent errors with the launch configuration. A similar Run Configuration does not generate the error.
This is caused by an invalid path somewhere in your Eclipse project settings. There are a couple common sources for this kind of error.
You're working on a shared (version controlled, copied, etc) project where someone has hardcoded a path that doesn't exist on your machine, or uses an environment variable that you've not set.
Sometimes, you can find the offending path by looking at the full list of Error messages. If not, look in your project file.
The Discovery Options in your project properties has 'Automate discovery of paths and symbols' enabled - but the process is generating an error.
If you're using a version of Eclipse that warns you this option is deprecated, uncheck the option to disable it and fix any includes in 'Preprocessor Include Paths' instead. If not. . .try it anyway.
Depending on your path changes, restart Eclipse and try again.
It starts the executable that was built last before you broke the build. That executable will be older then your source files. The reason you were able to debug is because your line numbers did not change for the code you've debugged - e.g. you may try break in main then introduce a compilation error and move main a couple lines below - the debug will highlight the wrong lines when it stops.
When doing remote debugging, some commands affect only the local debugger (the debugger on which the command is typed). Examples are:
.wtitle
.cls
.browse
.cmdtree
At the moment these are all looking like UI related commands. Are there more commands that are only executed on the local debugger?
My research effort:
I was googling for a list, but maybe the search terms are too common or I don't get them right.
I have also tried finding a reference in WinDbg help (.hh) itself. But the fact is not even documented on the affected commands I found so far.
I am aware that this is asking for a favorite external tools or reference. So if you really think this is off-topic, then vote for close.
All debugger processing, including all extension execution, is done in the core debugger process. So 99+% of commands all need to go to the debugger engine (the initial debugger instance)
The only commands that run only on the remote debugger are indeed a few UI related commands.
I will call out one pair of commands that is interesting on this topic which is the mostly commonly used remote debugger:
.srcpath sets the "source code path" in the debugger engine. This is where the debugger engine will get source information from if it's needed - for example, if a debugger extension wants to get to the source code.
.lsrcpath (l - for local) sets the "source code path" in the remote debugger. This path will be used in windbg (and cdb\kd also) to pull up source files in the UI.
Still not a complete list, but many commands that are not scriptable (MSDN) are affected:
.lscrfix // works on remote client only
.lsrcpath // works on remote client only
.open
.write_cmd_hist // writes local history only
.beep
.cls
.hh
.remote // Does not work in WinDbg anyway
However, the following ones from the list seem to work:
.idle_cmd
.restart
Regarding .write_cmd_hist: If you want to keep all commands executed during the debug session, it seems good to open a log file (.logopen) at the beginning of the session.
I'm currently working on a project on STM32F4 and I'm using Eclipse. I've got some problems with the program - it seems to have a random behavior - sometimes it works fine, other times it has some errors. Sometimes when I try do debug with breakpoints I get the beautiful HardFault Handler and it really messes with my brains.
Sorry for the little off-topic paragraph, just wanted to let you know why I decided to use printing to a log file at some key moments in the program so I can see in which states and in which functions does the problem occur. I'm debugging through a JTAG interface with Eclipse (gdb) and I need to know if there is an easy method integrated in Eclipse that may help me use fprintf-like functions inside my program to write to a file on the disk.
If no, any other solutions?
Thanks
I do not like to connect the debug output log to the Jtag communication port because the log will not be available after development.
I usually build an SystemLog library that can send the log messages through any medium that is available (UART, USB, Ethernet or SDCARD). That's what I'd recommend you to do. It will help you through the development, and the support team on the event of any failure on field.
If stdlib is available in your project you should use the snprintf family functions to build your SystemLog.
Also, you can integrate the log output to the eclipse console by calling a serial console communicator (if you use UART) on you makefile, in this case, your makefile will have to flash the target as well.
In Carbide 2.0.2, if I set active configuration to be "Phone Debug GCCE", build the project, go to Debug perspective, choose "Executables" tab, and select the executable file, Source File Name/Location window will list all the files I am able to use while debugging.
The problem is that the list does not contain all files from the project, even though their code is successfully linked and executed on a device. As a consequence of the issue, I am not able to set break points in these files.
What is the catch and how can I fix it?
Thank you.
This is a problem with the version of GCCE that is used by default with Symbian. It has a number of bugs with debug information, including sometimes missing line information for some files.
The alternatives are (a) the commercial RVCT compiler, or (b) follow the in-progress work to move to a newer GCCE compiler. A good start for that is here:
http://developer.symbian.org/wiki/index.php/The_GCCE_toolchain_initiative