[support]

Hi,

If you are using MSBuild, the map file should already be created in the same directory as the ELF file. You can also override it via the Linker Settings -> Advanced (e.g. to $(OutDir)file.map).

Based on our quick research, the -save-temps option always saves the temporary files in the current directory (VisualGDB sets this to the project directory so that relative paths specified in project properties would work as expected). The only way we could suggest to override it would be to add a custom post-build step that would move the generated files to $(OutDir).

Regarding the ELF files, we would advise diagnosing it as follows:

• Dump build command lines from both Eclipse and VisualGDB. E.g. using procmon. If you are using MSBuild, VisualGDB stores all command lines in the .rsp files, so you can simply reuse them.
• Build the project manually using both command line sets. Ensure that the ELF files still produce different results.
• Try linking the files compiled using the Eclipse command lines using the VisualGDB linker command line. This should tell if the problem is related to the linker or the compiler.
• If the problem is linker-related, compare the link command lines and try removing half of the differences to see if this fixes the problem. Repeating this a few times should help pinpoint the setting responsible for the error.
• If the problem is compiler-related, use a similar approach to pinpoint the source file causing the problem and then the command line argument causing it.

Unfortunately this does involve non-trivial amount of troubleshooting, however given the size/complexity of the project, it could be easier than trying to guess the offending setting otherwise.

[support]

Hi,

Sorry for the delay. It looks like 2 known issues:

1. You appear to be using lwIP in a mode where it tries to redefine the timeval structure that is already defined in the gcc toolchain. Double-clicking on the error message should open the related definition:

#ifndef LWIP_TIMEVAL_PRIVATE
#define LWIP_TIMEVAL_PRIVATE 1
#endif

#if LWIP_TIMEVAL_PRIVATE
struct timeval {
  long    tv_sec;         /* seconds */
  long    tv_usec;        /* and microseconds */
};
#endif /* LWIP_TIMEVAL_PRIVATE */

Simply defining LWIP_TIMEVAL_PRIVATE to 0 via Preprocessor Macros should resolve this (VisualGDB does it automatically when referencing lwIP via VisualGDB Embedded Frameworks, but cannot guess it if you are importing a 3rd-party project).

The problem with syscalls.c looks similar – please examine the file and modify it to avoid redefining the timezone struct.

2. You are building a source file meant for hardware floating point mode using a software FP setting. Please change the FP setting to hard via the first page of VisualGDB Project Properties.

[support]

Hi,

This looks like a configuration problem on your Raspberry Pi. Please try using a clean SD card image and installing Qt on top of it, or follow these instructions on repairing libEGL permissions.

[support]

Hi,

Looks like the underlying build process produced some errors that are not recognized by Visual Studio. Please use the View->Output window to see the entire build output and check it for error messages explaining what is going on.

[support]

Hi,

It looks like your support period has expired. To keep on receiving technical support please renew your support here: https://sysprogs.com/splm/mykey

[support]

Hi,

Yes, sorry it got delayed due to changes in kernel debugging of Raspberry Pi 3 vs. Raspberry Pi 2 . We have a relatively stable pre-release build available here: http://sysprogs.com/files/tmp/VisualKernel-3.0.1.2043.msi

We are still figuring out the last details and are expecting to release a beta this week.

[support]

Hi,

Thanks for the example. We have just tried reproducing this on a clean VS (with a native C++ project),  but unfortunately could not get the same behavior. Perhaps the behavior you are describing is caused by a 3rd-party add-in (e.g. Visual Assist?).

Either way, we could add an option for choosing what gets selected when you type “something->” or “something.”, although this would get a relatively low priority and will be included only in one of the late builds of v5.4.

[support]

Hi,

If closing all windows doesn’t help, please also ensure you don’t have the “show threads in source” option enabled. It would also result in Visual Studio querying all VisualGDB threads.

If you are not sure how to interpret the log file to find the critical paths from the timing perspective, please feel free to attach the log here (or send it to our support email) and we can check it for common problems.

The error message you mentioned looks like a gdb/gdbserver bug. Trying a different version of gdb might solve this.

[support]

Hi,

Sorry, this won’t work as VisualGDB would still try to specify “-G Makefile” internally. As a workaround, please modify the .vgdbsettings (or .vgdbcmake) file as shown below:

<Build xsi:type="com.visualgdb.build.cmake">
    <!-- ... -->
    <CMakeMakefileType>Ninja</CMakeMakefileType>
</Build>

We do agree that this workaround is inconvenient and will include a GUI setting for this in the next major update.

[support]

Hi,

Sorry, this is not yet supported, although is planned for the upcoming VisualGDB 5.4.

[support]

Hi,

No problem, we will try to provide an example.

Both VisualGDB and Visual Studio distinguish between the full match and partial match (see below):

Pressing enter with a full match (A) will substitute its value. Pressing enter with partial match (B) will create a new line.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Good to know it works. If you encounter further issues, don’t hesitate to create another topic.

[support]

Hi,

Sorry, we currently don’t have specific plans for supporting CMake-based stand-alone Android executables. The good news is that you can easily add multiple files and subdirectories to a VisualGDB project via Add->Add Existing Item->Import Folder Recursively.

[support]

Hi,

You could try changing the file order by manually editing the .vcxproj file, however there might be other minor differences between the 2 toolchains. We would advise trying to understand the potentially impactful differences between the projects (e.g. section size/alignment) instead, as making the output 100% identical may be impossible in reasonable time.

Different mapping should not affect the “Reset_Handler” behavior. Although it might interfere with debugging (VisualGDB will try several workarounds to restore the broken mapping though), it should allow understanding whether the problem is caused by debug settings or some ELF file properties.

With the weird memory location, to answer that definitively you would need to look into the Segger J-Link stub internals to see what kind of filtering they internally use. In our experience this error message comes up frequently when starting debugging and it never interferes with the actual program flow. Also explicitly trying to read invalid memory via debugger doesn’t trigger the fault handler.

You can add the extra commands via VisualGDB Project Properties -> Additional GDB commands.

[support]

Hi,

The “breakpoint-modified” message simply means that a breakpoint was either bound or unbound when a module containing the corresponding code was loaded/unloaded. Normally it should not reduce debugging speed.

You can try enabling diagnostic GDB logs on the Advanced GDB Settings page of VisualGDB Project Properties – the advanced gdb logs contain timestamps for each line received from gdb and allow understanding the timing.

It also looks like VisualGDB is querying stack traces for all threads in your example – this could considerably slow down stepping through the code. Please try closing the “threads” window in Visual Studio and VisualGDB will only query the stack trace for the current thread.

[Author]

Posts