cxx tool absolute source paths

182 views
Skip to first unread message

Erik Smith

unread,
Oct 8, 2022, 7:51:09 PM10/8/22
to gn-dev
We use a stack trace library, backward-cpp, that shows extra lines of source near the trace point.  This only works when the execution directory is the same as the compilation directory as GN constructs relative paths from the root_build_dir.    It would be nice if there was a way for GN to expand to absolute paths in the c/cxx tool so that the source is reachable regardless of the cwd.  Or alternatively, a way to set something at runtime (like $ORIGIN works for linking) so that tracing libraries get the correct path to source files.

Erik

Roland McGrath

unread,
Oct 8, 2022, 8:21:22 PM10/8/22
to Erik Smith, gn-dev
This is the default behavior of the compiler, in fact. One has to go to great pains to avoid absolute paths embedded in binaries' debug information when that's not what's desired.

In DWARF, the DW_AT_comp_dir for each CU is set to the absolute path of the build directory by default in compilers like Clang and GCC.  Then relative paths elsewhere in the DWARF data are understood to be relative to this directory.  There are various compiler switches such as `-fcompilation-dir` to affect what path goes there.

This is not really a GN issue.  You can use GN to pass whatever compiler flags you want to, and GN doesn't have an opinion about the details.

It's most likely not a compiler issue either if you are using default flags (i.e. just `-g` and no other special flags to avoid absolute paths).  It's most likely an issue in your DWARF-reading program's behavior not using DW_AT_comp_dir as specified.

But as to your GN question, I don't think there's a way to change the path expansion behavior of `{{source}}` et al that you use in the `tool()` clauses inside a `toolchain()` definition to tell GN how to run the compiler.  They're always relative to the build directory.  Of course, you entirely control what command those paths are passed to and what its command line looks like, so you can always use a wrapper that modifies paths however you like before invoking your actual compiler.
Reply all
Reply to author
Forward
0 new messages