[support]

Hi,

We normally recommend using the Custom build system with custom makefiles. The purpose of the “GNU Make” system is to provide a user-friendly front-end for GNU Make for those users who don’t want to go deep into customizing Makefiles and just prefer setting things like CFLAGS via GUI and expect everything to work out-of-the-box. So we intentionally keep the settings there simpler than in the Custom build subsystem.

[support]

Hi,

This error means that the debug symbols for your module do not contain enough information to find the memory address of the requested variable. It can happen due to a variety of reasons:

• Incompatibility between your gcc and gdb versions
• Incompatibility between the debug information format (e.g. DWARF 4) and your gdb version
• Missing “-ggdb” in your compilation flags
• Symbols being stripped from the executable after it is built
• Symbols not matching the loaded executables

We would recommend setting up a “hello, world” project using the same build/debug machines, ensuring that it works and then comparing compiler flags and gdb versions with your actual project in order to find out what exact difference breaks the variable viewing.

[support]

Hi,

You can find that out by disabling multi-threaded build via VisualGDB Project Properties -> Make Settings -> Build Command -> remove the “-j<number of CPUs>”  (so that all files are compiled one-by-one) and checking the last build command (will look like arm-eabi-gcc -c <file.cpp> -o <file.o> …) in the build log before the error.

Then you can replace -c with -E and <file.o> with <file.E> and run the command manually. This will run the preprocessor on the input file and save the preprocessed output to a file named <file.E>. The preprocessed output will show what exact macros got expanded and which parts of the files got compiled or skipped.

If you are still not sure, please simply send us the single-threaded build log and the .E file so that we could suggest a solution.

[support]

Hi,

This is a known bug that was recently fixed. Please try re-downloading the OpenOCD debug package again and if this does not help, update to VisualGDB 5.1r6.

[support]

Hi,

Not sure why the ‘make clean’ command starts the build. Are you using a custom Makefile?

Please try enabling the verbose mode in Tools->Options->VisualGDB->General->Output and selecting Build->Clean Solution. VisualGDB will then show what exact commands it runs.

If this does not help pinpoint the problem, please post the output of the verbose cleaning here so that we could provide further advice.

[support]

Hi,

That’s a known issue. VisualGDB automatically substitutes register names to support data tooltips for inline assembly. As a workaround please use the Locals window or rename your variables.

[support]

Thanks for the advice, we will consider that if Mono popularity continues to grow.

[support]

Hi,

Does the “libatk-1.0.so.0” file actually exist in the toolchain’s sysroot? If no, please resynchronize the sysroot via VisualGDB Project Properties.

[support]

Hi,

Could you please try evaluating the variable via the GDB Session window (“print <variable name>”)? Does this show correct values?

Perhaps the variable name is confused with something else, like a global variable with the same name of a register? Does the Watch window show correct value?

[support]

Hi,

We do have plans on adding more mbed tutorials, but not before the v5.2 release at the end of summer. If you have some specific topics you would like to see covered, let us know and we will address those first.

[support]

Hi,

Please try the __attribute__((__interrupt__(vector))) syntax described here: http://stackoverflow.com/questions/15500826/how-to-declare-an-interrupt-handler-isr-in-mspgcc

[support]

Hi,

VisualGDB has its own mechanism for handling signal behavior. Please use the ‘signals’ button in the GDB Session window (the yellow lightning bolt icon). This will set the signal settings properly and remember them for the next session.

Regarding C# debugging, gdb does not support this out-of-the-box, however VisualGDB SDK has an interface for parsing high-level frames (i.e. extracting code location and variable values by manually interpreting the values of the normal C/C++ variables or CPU registers). If you are willing to figure out how to extract that data for Mono frames, yes you can easily hook that up to VisualGDB and we can provide more details on that.

[support]

Thanks for reporting this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.1.719.msi

[support]

Hi,

So far it looks like a fairly rare scenario that could be easily automated with custom actions, however we’ll keep on watching this thread. If we get more feedback from other users that this would simplify things a lot, we will add it to one of the next releases.

[support]

Hi,

VisualGDB already supports mbed. Please see this tutorial for details (step 9 shows how to reference various libraries).

[Author]

Posts