Portable VisualGDB Project

[LukeK]

Hi All,

I’ve just recently got VisualGDB going for development on an STM32F1x series target. To get this all going, I installed all the necessary applications (GNU GCC for ARM, OpenOCD and make tools etc) and in the flags.mak and VisualGDB project properties, I gave full paths for everything so that everything compiled and debugged. Now that I’ve got it all going, I would like to setup the project to be portable so that other developers could co develop on this project. By being portable, I mean I would like to setup all paths to be relative so that all dev tools (open OCD, GCC, make) can be checked into source control and all a developer needs to is have VisualGDB & Visual Studio installed, check out the project and everything just works out of the box. When I look at the flags.mak and the properties of the VisualGDB project, it just occurs to me that this may not be possible – I see a lot of absolute paths, especially with the VisualGDB environment globals.

Is it possible to make the VisualGDB purely portable, or at least as close to this as possible?

Thanks in advanced,
Luke

[ket]

Hi,

In flags.mak you can use the system environment variables as those are passed to make. In VisualGDB Project Properties you can use the VisualGDB Build variables, you can see the defined variables from the link in the lower left corner of the VisualGDB Project Properties window.

For the next release of VisualGDB a new feature is planned that will allow to define your own variables with user-specific values.

[LukeK]

Hi Ket,

Thanks for your reply. When would we be expecting this next release?

I also have a question regarding include paths. For IntelliSense to work properly, I find myself configuring either the VisualGDB project properties under “IntelliSense includes” or by configuring the VS project include directories. For compiling to work properly, I then find myself replicating all these paths in the flags.mak so the compiler can use these paths too. Is there a way to reference the project variables in the flags.mak so I that I can maintain only one include paths variable?

[support]

Hi,

Unfortunately this is not possible in the currently available release, however it will be significantly improved in the upcoming release.
The beta is scheduled to be released within a month from now.

[LukeK]

Thanks for the update. In an attempt to get around this portability issue, I created a subst a drive to the actual path and included source files from the subst drive into my VisualGDB project. What I found was that after I compiled and connected to the target, I can’t seem to set any breakpoints.

Here’s a dump of the output from the GDB server when using my subst T:

-break-insert -f T:/embedded/rtcd/src/main.cpp:45
&"No source file named T:/embedded/rtcd/src/main.cpp.n"
^done,bkpt={number="3",type="breakpoint",disp="keep",enabled="y",addr="",pending="T:/embedded/rtcd/src/main.cpp:45",times="0",original-location="T:/embedded/rtcd/src/main.cpp:45"}

I then swapped one of the files in the project out (the one containing main) with the same file, but specified from its absolute path and I was able to set breakpoints again.

Here’s a dump of the output from the GDB server when using the absolute path:

info line *0x800262c
&"info line *0x800262cn"
Line 45 of "D:/views/svn/C002/TestProject_SW/embedded/rtcd/src/main.cpp" starts at address 0x800262c  and ends at 0x800264c .

OK

Any ideas on why or what could be causing this problem?

[ket]

This issue was caused by gdb reporting non-expanded paths and not recognizing the expanded absolute paths. A work-around was added in VisualGDB version 3.1.r5. VisualGDB will now try to fix breakpoints by using the path that gdb reports.

[Author]

Posts