Forum Replies Created
-
Posts
-
Good to know it works. If you encounter further issues, don’t hesitate to create another topic and we will be happy to help.
No worries. For CMake projects the implicit toolchain directories are indeed cached in the VisualGDBCache directory, although they should get invalidated when the gcc executable changed. The only exception would be if you changed gcc via your own CMake scripts (not maintained by VisualGDB), but kept the old toolchain in the VisualGDB settings.
Hi,
We have tried reproducing this with a simple MinGW-based project (running notepad.exe after gdb exits) and it did work as expected, so the problem is likely triggered by some specific combination of settings.
Please try reproducing it on a freshly created project and share the archive with the project so that we could see what is going on. Also if you discover that the problem is specific to a particular project type, or a particular scenario that can be reproduced without the project archive, please let us know.
Thanks for the update. Unfortunately it looks like the latest MinGW-W64 toolchain does not include boost as a pre-built package, so in order to reproduce this we would need to build it from scratch (that might result in different results due to slightly different configuration).
We have tried reproducing the problem you described using a Linux VM after installing boost as a package, however we could not get the behavior you described. It also looks like the code you pasted is not from an actual project (it had a missing semicolon and a typo in the class name). Unfortunately problems like this one are often triggered by a rare combination of small factors and a rough description of the setup without the exact repro setup will not be sufficient.
You don’t need to share any production code, you could simply try reproducing the problem on a newly created project with the dummy classes, ensure that it behaves the same way and send us a link to the archive containing the project along with all dependencies (e.g. the toolchain and boost). There will be a high chance we will manage to reproduce the behavior on our side and fix it or suggest a workaround.
P.S. If you are using boost, please consider copying the boost includes to a separate header file and setting it as an IntelliSense-only precompiled header (VisualGDB Project Properties -> IntelliSense Settings). This will dramatically improve IntelliSense performance as VisualGDB will be able to cache the boost headers instead of reparsing them each time you change one of your own headers.
Are you using VisualKernel to build the kernel itself, or have you already built and installed it manually?
Hi,
VisualGDB also queries the explicit/implicit directories from gcc. Depending on your project type, this is done during the toolchain testing or during the project load.
If you believe it is not working, please let us know your project type (i.e. whether you are using Advanced CMake and whether the project is built on the Windows or Linux machine) and we will help you get it to work.
Thanks for clarifying this. Is it a remotely built Advanced CMake project? If this is the case, VisualGDB tries connecting to the remote machine in order to query the code structure from CMake (this ensures that the project structure shown in Solution Explorer exactly matches what will be actually built).
If you have previously opened the same project on the same machine, you can cancel the connection so that VisualGDB will display the cached project structure, however the project editing functionality that depends on getting updated information from CMake (e.g. adding new files to targets) won’t work.
If you don’t want to have continuous access to the Linux VM, please consider using a Windows cross-toolchain instead. In this case CMake will run on the Windows machine, so no remote connection will be required until you start debugging.
Not sure what you meant. Please try attaching a screenshot of the problem, showing what you are trying to achieve and what you actually observe and we will help you get it to work.
The second last line can be ignored. It just means that VisualGDB closed the connection without issuing the proper shutdown command and it shouldn’t matter for connection tests.
This time it actually looked like a successful test, so you should be able to debug your project now, although all we changed in that build was adding extra logging, so the problem might reoccur later.
Thanks for the update. We have updated the temporary build to include more logging. Please try this one (same link): http://sysprogs.com/files/tmp/openocd.exe
Sorry, not sure what your question was. If you could provide an example of what you are trying to achieve, we should be able to help you find the correct setting.
Thanks for the detailed description. Since this could be caused by a specific version of Boost, could you please share an archive with your MinGW toolchain (including the boost version you are using)?
You can upload the archive to any file sharing service (e.g. Dropbox) and either share a link here, or report it via our support form.
Hi,
This looks like an incompatibility between OpenOCD and your USB driver. Please try replacing the OpenOCD executable in %LOCALAPPDATA% with this one: http://sysprogs.com/files/tmp/openocd.exe
If it doesn’t work, please share an updated OpenOCD output.
No problem. It looks like we will need to know more details about your setup (specific installation IDs) and may need you to run our internal diagnostic tool in order to see what is going on. Please create a support ticket here and we will get back to you with details.
No problem. Just a heads up that you may still qualify for a 50% renewal discount (that will add 1 year to the previous expiration date even if it’s in the past or in the future), Simply use this page to get an automatic renewal quote.
