- This topic has 3 replies, 2 voices, and was last updated 3 years, 7 months ago by
.
-
Posts
-
Hi,
In my test environment I often run into issues with path mapping. The hosts I’m testing on are quick spin-up, throw-away VMs in our local build/test farm. I can go through many of these VMs on one day. Unfortunately they are configured such that any mount you add to them will go via a symlink, that when resolved will have a random generated absolute path (e.g. /foo/634-546ab-456/bar, or whatever).
Both GDB and VGDB don’t seem to transparently work with symlinks. For GDB I need to change the mappings each time to use whatever the new absolute paths might be, e.g. to remap where GDB looks for source files, debug symbols etc, and also VGDB’s own path mappings.
I am using a custom debug step in VGDB to do a readlink so it resolves the absolute path and stores that value in a user variable. That variable is then used in the VGDB path mapping window.
That usually works, but the problem I run into is that sometimes I just can’t get it to work, and VGDB insists on downloading the source file from the host, no matter what I try. So somewhere a path mapping is really misconfigured, but it is almost impossible to root cause.
So my question is… Is there somewhere I can see the exact path(s) that VGDB tried before it gave up and downloaded the source file? Maybe some verbose VGDB logging that will log these attempts. That would help a lot in knowing where exactly the issue is. Between making GDB happy, as well as VGDB wrt to symlinks can sometimes waste a lot of time. So if I have more insight into exactly how VGDB is trying to resolve the paths, it would help a lot!
Thanks in advance for your help!
Hi,
Indeed, VisualGDB does not query symlinks each time due to performance constraints. It expects you to configure the path mappings that would work with the paths reported by gdb via VisualGDB Project Properties.
You can recheck the paths via the GDB Session window. Simply locate the path reported by gdb in the gdb log and match it against the list of mappings shown when you click the “Edit Path Mapping” button. The window will show the exact mappings used by VisualGDB, including the ones inherited from the toolchain.
OK thanks, I will follow those steps next time and see if I can resolve the path mappings easier.
Somewhat related…
I believe I tried to use a VGDB user variable that was previously set via a Custom Debug Step in the Additional GDB Commands window, e.g:
set substitute-path $(ResolvedSymlinkPath)/foo /bar
However this did not work AFAICT.
Do you believe this could work if I set an env var under Debug settings -> Environment from the captured user variable from the Custom Debug Steps, and then instead do:
set substitute-path ${ResolvedSymlinkPath}/foo /barI’m going to try that regardless but it is sometimes hard to tell what GDB is doing with the paths.
Hi,
Using the custom debug step (before launching debugger) should work. If you believe it doesn’t, please share the screenshots of all the relevant settings and the gdb log showing the commands sent by VisualGDB, and we will look further into this.
- You must be logged in to reply to this topic.