[support]

Hi,

It’s a known bug that will be fixed in the next maintenance release. As a workaround, please switch the GDB mode to “Custom mode”, then click “customize” in the gdbserver command editor and specify your variables there.

[support]

Hi,

We are not targeting Atmel devices because Atmel provides their own IDE (Atmel Studio). However you can add new devices to VisualGDB by creating a board support package. Essentially you will need the following information:
1. GCC command-line switches for your target (typically -mcpu=cortex-XXX and various definitions).
2. a linker script for your target
3. startup code provided by the device manufacturer.

All those are typically present in the GCC sample projects provided by device manufacturers. In order to integrate these settings into VisualGDB you could try 2 different approaches:
1. Select “Specify flags manually” in the VisualGDB Project Wizard
2. Create your own BSP based on one of our ones stored in %LOCALAPPDATA%VisualGDBEmbeddedBSPs. The information is stored in XML files that could be easily edited.

Let us know if you need more details.

[support]

Hi,

It looks like VisualKernel fails to detect the port used by your VMWare stub. Which VMWare version are you using? If it’s an old one, it may have bugs related to the VM control API that VisualKernel is relying on.
Does VisualKernel show the “suspending VM/configuring VM/resuming VM” window?
Does your VMX file contain the following lines? (VisualKernel should add them if they are missing)

debugStub.listen.guest32 = 1
debugStub.listen.guest32.remote = "TRUE"
debugStub.hideBreakpoints = "FALSE"

If not, please try adding them manually and suspending/resuming the VM.

Does your vmware.log file contain lines similar to the following?

2014-04-06T12:15:45.346-07:00| vmx| W110: VMware Workstation is listening for debug connection on port 8832.
2014-04-06T12:15:45.346-07:00| vmx| W110:     target remote localhost:8832

If not, please send us your vmware.log file.

[support]

Hi,

Based on your log it looks like you are out of free space on your Linux machine. Note that the kernel sources and symbols need several gigabytes of space. Could you please try freeing up some space (e.g. adding another virtual disk and mounting /usr/src there)? Does it solve the problem? You can check your free space on Linux using the ‘df -h’ command.

[support]

Hi,

Sorry, looks like there is a bit of confusion here. Please let me know if I understand correctly that:
1. Touch screen works if you launch the app from the console.
2. Touch screen does not work if you launch the app using SmarTTY.

If that is correct, please obtain the ‘env’ output from the console (not using SmarTTY). E.g. run “env > /tmp/env.log” in the console and then cat /tmp/env.log with SmarTTY to copy-paste its contents.
The environment in SmarTTY will not be affected by running the app from console, however the environment in a SmarTTY session can be different from the environment in the console session and those differences can be causing touchscreen problems.

[support]

Hi,

Are you using a single-machine or a two-machine setup? What directory have you selected to store the kernel cache?
Could you please enable the verbose mode (Tools->Options->VisualKernel), try debugging again and see if the Launcher Output (in the Output window in VS) contains any additional information such as command line that VisualKernel tries to run?

[support]

Hi,

This probably happens because the default session has some environment variables that point Qt to the touch screen. Please try the following to diagnose it:
1. Run your app from an SSH session (e.g. using SmarTTY or open it in VisualGDB). Ensure that the screen is not working.
2. Compare the environment variables in the SSH session and environment variables in the console session (the output of env).
3. Try setting relevant variables in the SSH session. See if this fixes the problem.

Once you figure out the correct variables, please specify them in the VisualGDB Project Properties so that VisualGDB can set them automatically.

[support]

Hi,

Sorry for the late reply. We will be most likely making a new release of SmarTTY within the next 3 months. We will try including most of the suggested features there. Support for multiple servers in one instance, however, may be delayed, as it would require significant changes to the internal architecture.

[support]

Hi,

You could modify the makefile to build/use precompiled headers manually. Add the following lines to it before the FileSpecificTemplates line:

PRECOMPILED_HEADER_FILE := stdafx.h.gch
stdafx.h.gch: $(all_make_files) stdafx.h
$(CXX) $(CXXFLAGS) -c stdafx.h -o stdafx.h.gch -MD -MF $(BINARYDIR)/stdafx.dep

-include $(BINARYDIR)/stdafx.dep

Then modify FileSpecificTemplates this way:

$(BINARYDIR)/%.o : %.cpp $(all_make_files) $(PRECOMPILED_HEADER_FILE) |$(BINARYDIR)
$(CXX) $(CXXFLAGS) -c $< -o $@ -MD -MF $(@:.o=.dep)

Note that this solution will have one major disadvantage: The precompiled header file will be shared between debug/release builds, so you will need to delete it before building the other configuration. You can fix it by creating the gch file inside $(BINARYDIR), but then you will need to add it to the beginning of the include directory list and ensure it is always there before the '.' directory.

[support]

Hi,

Windows 8.1 has several known issues with video drivers. It is unlikely that your issue is related to WinCDEmu. Please try installing Windows 8 instead.

[support]

Hi,

This is caused by a limitation of most SSH servers (they don’t accept more than 10 concurrent channels within one session) and VisualGDB currently does not have a workaround for that.
Normally Visual Studio treats all of your projects as independent ones and tries building them at the same time. Is it intended? If no, please add dependencies between projects so that VS can wait for project A to build before starting to build project B. If yes, please add some arbitrary dependencies to reduce the amount of simultaneously built projects to 5.

[support]

Please use support at sysprogs dot com.

[support]

Hi,

It is always very hard to diagnose such problems without seeing the full GDB log because in most of the cases the root cause is some tiniest difference between different representations of a path. Can you reproduce the problem on a ‘hello, world’ project on the same machine? The only thing we can do is show you the GDB logs on our side demonstrating normal VisualGDB behavior so that you can compare them with yours and search for abnormalities.

Regarding the breakpoint that is shown as unresolved, looks like it corresponds to multiple addresses, but GDB does not report them in a way VisualGDB expects it. Here’s a sample response from setting a breakpoint in a template function that has 2 instances:

^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="",times="0",original-location="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp:7"},{number="4.1",enabled="y",addr="0x080486fd",func="f<1>()",file="LinuxProject10.cpp",fullname="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp",line="7"},{number="4.2",enabled="y",addr="0x08048707",func="f<2>()",file="LinuxProject10.cpp",fullname="/tmp/VisualGDB/e/PROJECTS/TEMP/LinuxProject10/LinuxProject10/LinuxProject10.cpp",line="7"}

Your output looks different. Which platform/GDB version are you using?

Regarding path mapping, here’s a sample path mapping that maps /tmp/test to c:something:
[attachment=1:1xtzhfzt]pathmapping.png[/attachment:1xtzhfzt]
Here’s how the /tmp/test/test.h is mapped to c:somethingtest.h:
[attachment=0:1xtzhfzt]sourcelist.png[/attachment:1xtzhfzt]

Does it work for you with exactly the same paths? Do you have any symbolic links involved (e.g. /tmp is mapped to /system/tmp and while you set /tmp, GDB reports it as /system/tmp)?

If a breakpoint shows as resolved but is not hit, does the code at the address reported by GDB match the expected function body (e.g. is it equivalent to the disassembly of your ELF file)? If yes, does placing a manual breakpoint there (asm (“int3”); if you are using GCC) work? Can the memory be write-protected so that GDB fails to set the breakpoint?

Are you running GDB on your target machine or are you using a gdbserver? Are you using a .vgdbsettings file or quick debug?

[support]

Hi,

The sources don’t need to be copied the the debug machine. Does the breakpoint reply contain the address it was resolved to or is it marked as ‘pending’? Can you send us the full GDB log? This will help us diagnose the problem further.
The manual mapping should work with any path prefix (try restarting debug session if it’s not updated immediately). E.g. if you want to map /usr/buildmachineproject/code/somefolder to c:projectcodesomefolder, you need to create the following mapping:

Linux path: /usr/buildmachineproject/code
Windows path: c:projectcode

If this still does not work, please send us the screenshots of your source file mapping window and the window showing incorrectly mapped paths.

[support]

Hi,

Your mapping seems to be set correctly and should work. Please follow the instructions below to diagnose it:
1. In the GDB Session window select ‘all GDB interaction’ so that VisualGDB shows the commands it sends to GDB automatically.
2. Set a breakpoint in a problematic file. VisualGDB will issue a -break-insert command. GDB will report whether it has been resolved.
3. If the breakpoint shows as unresolved, please run the following commands:
* info shared – this will show the loaded shared libraries. Ensure that the library that contains your code is loaded.
* info sources – this will list all source files known to GDB

If your library is not listed in the output of ‘info shared’ it has not been loaded yet, so please ensure it gets loaded and then repeat setting the breakpoint. If the library is shown and has the symbols loaded, but the ‘info sources’ does not list your source file among the source files, there is some problem with your symbols (either GCC is a lot newer or older than GDB or you are missing the -ggdb flag or you are stripping some symbols during build). If the file is shown, please compare the exact path of the file reported by ‘info sources’ with the path that VisualGDB used in the ‘-break-insert’ command. If they don’t match, you need to adjust the path mapping until they match.

[Author]

Posts