[ket]

Hi,

This error just indicates that build has failed. Please look in the Output window (View->Output if the window is not already shown) to see the cause for the error.

[ket]

Hi,

Thanks for noticing this bug. We will include a fix to this in our next r release of VisualGDB, which we will release as soon as possible.

[ket]

Hi,

Qt5 is not yet available as a package for Raspberry Pi. That is why we currently support auto-installing Qt4 packages only as in the tutorial. You can still use Qt5 with Raspberry Pi, but you will need to set it up manually. Currently that probably means building it from sources yourself.

[ket]

Hi,

1. The include paths should be absolute. If you use relative paths in the settings, then the paths should always be relative to the working directory of gcc/make i.e. the project directory. The include statements inside source files should be relative to the source file’s location or to one of the specified include directories.
2. As it is not a blocking issue or a bug, next version of VisualGDB.
3. MCU.xml? It is a helper file for vgdbsettings, it specifies the mcu settings.
4. Thanks for noticing this, it is a gui bug. The target device field lists all the options available as well as allowing to specify the target device manually. As LPC4330_M4 is not listed in the available options, it looks like the closest match is selected next time the settings are loaded. However, this is only a visual bug, the manually specified value is saved correctly. Unless you change anything on the debug settings page, the saved value will not be overwritten with the wrong value. We will be releasing a fix for this soon.

[ket]

Hi,

1. Absolute paths with a forward slash (e.g. e:/dir/file.c) are expected (Windows normally uses the back slash) for include directories in embedded projects.
2. The list editors always put the dividers automatically, so you can use that to see which separator is used in each place. For include directories the divider character is space.
3. The .mak files warn against editing because VisualGDB expects some structure in the .mak files. Basically, it is safe to modify the value of assignments like A := B (VisualGDB will pick that up), but if you add more complex things like ifdef, += or something similar, it could confuse the project properties dialog and end up being overwritten if you edit things through the dialog. In some cases (e.g.) source files list, the values are also set automatically by VisualGDB. You can however edit the makefiles if you keep the above in mind, in general it is also safer to add your own variables and rules instead of editing the existing. The settings set in Makefile settings are stored into the makefiles, all other settings are stored in the VisualGDB project file (.vgdbsettings).
4. Sorry, it’s hard to understand the problem based on your description. Could you please attach a screenshot or provide more details?

One thing that would really help is a better include path editor. There is no way to paste a path to a folder directly into the dialog list. The only route is to use the painfully slow XP style folder picker.

That is actually already in the planned features list. With remote Linux directories we use our own dialog that allows pasting as well, for Windows directories we use the default Windows folder dialog. We are not happy with its usability either and will be making it more usable.

Also, how about automatically converting absolute paths to project relative ones?

In certain VisualGDB settings that is already done. Sometimes we set the paths according to build variables, sometimes relative. For include directories if you use the editor we use the path style from the Path mapping page. For directories that go into makefiles, we usually do not make them automatically relative because toolchains may not like it and we like to leave the choice to the user.

[ket]

Hi,

1. Thanks for the description, we will look into it.
3. Thanks for the idea, we will definitely consider it.
4. Please try specifying the sysroot location to gdb with “set sysroot” as suggested. Only the -file-list-exec-source-files command is slow with very many source files, that is why we allow disabling the use of it in GDB settings. VisualGDB itself does not have any source file amount limitations.
5. Yes, we can add an option to kill the gdbserver as well when debugging exits. We will just not enable it by default as it is normally not needed. Unless you have several debug sessions open on the same device killing the gdbserver is easy, just add a post-debug command “killall gdbserver” to be executed on the target. Killing the gdbserver will kill also the executable as gdbserver starts it.

[ket]

Hi,

The error can very well be triggered only for VisualGDB projects. Their tool could likely be assuming something about debug sessions that only holds for Windows or standard Visual Studio project debug sessions. Then at the end of the debug session their assumption does not hold and the error is not silently handled. Nevertheless, this is not something we can fix on our side.

[ket]

Hi,

1. It is strange that cleaning happens twice on rebuilding, it should only happen once. We would need to replicate the issue to see where the problem is. Are you using the latest version of VisualGDB? Which exact project type do you have (e.g. is it a Linux project with two machines, one for building, other for deployment)? Are you using a VisualGDB generated makefiles or your own?
3. We use on-the-fly TAR generation that is quite fast compared to file-by-file transfers. Do you have benchmark results showing that rsync is better? Do you believe it’s due to compression or something else? How does it scale with the amount of files (e.g. 1 huge file vs 10000 small files)? How does it scale with file compressibility (e.g. huge source file vs a ZIP archive)? Note that you can setup rsync-based file transfer via custom actions.
4. As noted in the email answer, enable the relative source paths option in GDB settings to avoid the timeout caused by the “-file-list-exec-source-files” command.
5. In the majority of cases killing the gdbserver separately is not needed. Have you tried changing the action for the stop debugging command in GDB settings? For your toolchain gdb may expect to be stopped in a different way for gdbserver to be killed.

[ket]

Hi,

Based on the call stack below, the error seems to be thrown by the Intel OpenCL SDK dll (icldbgcfg.dll). The error does not seem to be related to VisualGDB at all, as VisualGDB is not mentioned in the entire call stack and as it seems to be icldbgcfg.dll trying to delete its own registry keys. Also, as there is no source available for icldbgcfg.dll, we cannot look into its functions. As such you may want to contact Intel OpenCL SDK support for help about the error.

 	[Managed to Native Transition]
>	System.Windows.Forms.dll!System.Windows.Forms.MessageBox.ShowCore(System.Windows.Forms.IWin32Window owner, string text, string caption, System.Windows.Forms.MessageBoxButtons buttons, System.Windows.Forms.MessageBoxIcon icon, System.Windows.Forms.MessageBoxDefaultButton defaultButton, System.Windows.Forms.MessageBoxOptions options, bool showHelp)	Unknown

icldbgcfg.dll!Intel.OpenCL.Tools.RegistryHelper.Delete(uint PID)	Unknown

icldbgeng.dll!Intel.OpenCL.Tools.OCLDebugEnginePackage.Microsoft.VisualStudio.Debugger.Interop.IDebugEventCallback2.Event(Microsoft.VisualStudio.Debugger.Interop.IDebugEngine2 pEngine, Microsoft.VisualStudio.Debugger.Interop.IDebugProcess2 pProcess, Microsoft.VisualStudio.Debugger.Interop.IDebugProgram2 pProgram, Microsoft.VisualStudio.Debugger.Interop.IDebugThread2 pThread, Microsoft.VisualStudio.Debugger.Interop.IDebugEvent2 pEvent, ref System.Guid riidEvent, uint dwAttrib)	Unknown

[Native to Managed Transition]

[Managed to Native Transition]

Microsoft.VisualStudio.Shell.11.0.dll!Microsoft.Internal.VisualStudio.PlatformUI.DataSource.Invoke(string verb, object pvaIn, out object pvaOut)	Unknown

Microsoft.VisualStudio.Shell.UI.Internal.dll!Microsoft.VisualStudio.PlatformUI.VsCommand.Execute(object parameter)	Unknown

PresentationFramework.dll!MS.Internal.Commands.CommandHelpers.CriticalExecuteCommandSource(System.Windows.Input.ICommandSource commandSource, bool userInitiated)	Unknown

PresentationFramework.dll!System.Windows.Controls.Primitives.ButtonBase.OnClick()	Unknown

PresentationFramework.dll!System.Windows.Controls.Button.OnClick()	Unknown

PresentationFramework.dll!System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(System.Windows.Input.MouseButtonEventArgs e)	Unknown

PresentationCore.dll!System.Windows.UIElement.OnMouseLeftButtonUpThunk(object sender, System.Windows.Input.MouseButtonEventArgs e)	Unknown

PresentationCore.dll!System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(System.Delegate genericHandler, object genericTarget)	Unknown

PresentationCore.dll!System.Windows.RoutedEventArgs.InvokeHandler(System.Delegate handler, object target)	Unknown

PresentationCore.dll!System.Windows.RoutedEventHandlerInfo.InvokeHandler(object target, System.Windows.RoutedEventArgs routedEventArgs)	Unknown

PresentationCore.dll!System.Windows.EventRoute.InvokeHandlersImpl(object source, System.Windows.RoutedEventArgs args, bool reRaised)	Unknown

PresentationCore.dll!System.Windows.UIElement.ReRaiseEventAs(System.Windows.DependencyObject sender, System.Windows.RoutedEventArgs args, System.Windows.RoutedEvent newEvent)	Unknown

PresentationCore.dll!System.Windows.UIElement.OnMouseUpThunk(object sender, System.Windows.Input.MouseButtonEventArgs e)	Unknown

PresentationCore.dll!System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(System.Delegate genericHandler, object genericTarget)	Unknown

PresentationCore.dll!System.Windows.RoutedEventArgs.InvokeHandler(System.Delegate handler, object target)	Unknown

PresentationCore.dll!System.Windows.RoutedEventHandlerInfo.InvokeHandler(object target, System.Windows.RoutedEventArgs routedEventArgs)	Unknown

PresentationCore.dll!System.Windows.EventRoute.InvokeHandlersImpl(object source, System.Windows.RoutedEventArgs args, bool reRaised)	Unknown

PresentationCore.dll!System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject sender, System.Windows.RoutedEventArgs args)	Unknown

PresentationCore.dll!System.Windows.UIElement.RaiseTrustedEvent(System.Windows.RoutedEventArgs args)	Unknown

PresentationCore.dll!System.Windows.UIElement.RaiseEvent(System.Windows.RoutedEventArgs args, bool trusted)	Unknown

PresentationCore.dll!System.Windows.Input.InputManager.ProcessStagingArea()	Unknown

PresentationCore.dll!System.Windows.Input.InputManager.ProcessInput(System.Windows.Input.InputEventArgs input)	Unknown

PresentationCore.dll!System.Windows.Input.InputProviderSite.ReportInput(System.Windows.Input.InputReport inputReport)	Unknown

PresentationCore.dll!System.Windows.Interop.HwndMouseInputProvider.ReportInput(System.IntPtr hwnd, System.Windows.Input.InputMode mode, int timestamp, System.Windows.Input.RawMouseActions actions, int x, int y, int wheel)	Unknown

PresentationCore.dll!System.Windows.Interop.HwndMouseInputProvider.FilterMessage(System.IntPtr hwnd, MS.Internal.Interop.WindowMessage msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled)	Unknown

PresentationCore.dll!System.Windows.Interop.HwndSource.InputFilterMessage(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled)	Unknown

WindowsBase.dll!MS.Win32.HwndWrapper.WndProc(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam, ref bool handled)	Unknown

WindowsBase.dll!MS.Win32.HwndSubclass.DispatcherCallbackOperation(object o)	Unknown

WindowsBase.dll!System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate callback, object args, int numArgs)	Unknown

WindowsBase.dll!MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(object source, System.Delegate method, object args, int numArgs, System.Delegate catchHandler)	Unknown

WindowsBase.dll!System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority priority, System.TimeSpan timeout, System.Delegate method, object args, int numArgs)	Unknown

WindowsBase.dll!MS.Win32.HwndSubclass.SubclassWndProc(System.IntPtr hwnd, int msg, System.IntPtr wParam, System.IntPtr lParam)	Unknown

[Native to Managed Transition]	

[ket]

Hi,

If you add include directories on the Makefile settings page, then the same directory is also added to IntelliSense directories and cached if it did not exist before. So, the IntelliSense support is automatic.
The IntelliSense cache is not refreshed at each build because it would take too much time, but it is refreshed when new include directories are added. You can also refresh it manually in VisualGDB Project Properties on the IntelliSense directories page or globally for that machine in Tools->VisualGDB Source Cache Manager.

If you add library names on the Makefile settings page e.g. usb, they get passed to the linker exactly like -lusb. As passing library directories and names to the linker is done in a standard way, VisualGDB makefiles have separate fields for them and adding the appropriate prefix is automatic. You should only need to use the additional linker inputs field if adding something non-standard that should be passed to the linker as-is.

[ket]

Hi,

If you are not using a cross-compiler then the library and its headers are not needed on the Windows host. This is because building takes place on the Raspberry Pi target, the sources of your project are transferred over to the target over SSH just before building, all the libraries are constantly on the target.

You do need to tell the project which libraries and include directories you are using. You can do that on the Makefile settings page in VisualGDB Project Properties. Add the include directory there and the library name without the lib prefix and type suffixes (for libusb that is probably just usb). Normally the linker should search common library directories, but if the library is not found then add the library directory as well in the settings.

[ket]

Hi

Thank you for the bug report.
This is a very strange error to have, but we have managed to reproduce it on our side. We will be looking into making a fix for it.

[ket]

Hi,

You can add pre-build and post-build steps on the Custom build steps page in VisualGDB Project Properties, they can be run locally or on remote machines. The Custom build steps page is available in VisualGDB Custom and Ultimate editions.

[ket]

Hi,

That looks strange. Could you please give us the dump file?
When this error happens, go to Task Manager and right-click on the Visual Studio process and choose “Create Dump File”.
If the file is huge, then you can use a service like Dropbox.

[ket]

Hi,

Thank you for for the kind words.

Below are the answers to your points:
1. What exactly do you mean by nothing happens? What does the Output window say after executing those commands? Please check that the build and clean commands are set in VisualGDB Project Properties. If they look fine, then check the Properties of the project to see if the NMake commands are calling VisualGDB.

2. That was recently suggested and has been added to the feature roadmap.

3. If you need to copy many files, then consider switching to using shared directories instead. You can also disable the file synchronization and use your own synchronization command in pre-build commands.

4. We would need to see the full gdb log to be able to tell what the cause is here. Please enable gdb logging on the GDB settings page in VisualGDB Project Properties. Then start debugging, replicate your scenario, stop debugging and give us the gdb log from your project directory.

5. This is because sometimes you may want to attach to the running instance instead. Normally when gdb is detached, gdbserver should die together with the app. If this does not happen, add a pre-debug or post-debug command to kill the gdbserver or modify in GDB settings which command should be executed when debugging is stopped.

[Author]

Posts