Use relative path in DW_AT_comp_dir if possible #3828
Conversation
dee66ca started enforcing the use of absolute paths in DW_AT_comp_dir which results in the following issue. After compilation is done and one wants to debug their binary on their deployment machine they will need to transfer both the binary and the sources directory. As a result any absolute paths in the dwarf info will now be invalid. However, if the sources directory are kept in the expected relative-to-the-binary path, a relative DW_AT_comp_dir will remain valid and gdb (as well as other tools) will be able to pick the sources up without any additional configuration (e.g. `directory path/to/sources/` in gdb.
|
@adinn can you please review this? |
There was a problem hiding this comment.
Ok, so just to recap:
This only affects the case where option DebugInfoSourceCacheRoot is provided as a relative path (or defaulted to sources). In this case the cache is still correctly created relative to the output dir (e.g. /path/to/output/my/configured/sourcedir) rather than the current working dir. However, in the debug info the DW_AT_comp_dir value will no longer be that same absolute path. Instead it will simply be the configured value (e.g. my/configured/sourcedir).
The implication of this change is that when the binary is being debugged a source for org.my.Foo will -- as a default -- be looked for using path my/configured/sourcedir/org/my/Foo.java. Previously it would have been looked for as /path/to/output/my/configured/sourcedir/org/my/Foo.java i.e. it is interpreted relative to the debugger's current working dir. So, with this change the path will only be correct during development if the program is debugged with output dir as the working dir for the debugger. Previously it would always find the cached sources. Of course this can be fixed by configuring gdb with a source search path that points to /path/to/output/my/configured/sourcedir but this is going to make the developer perform an extra step.
By contrast, on the deployment side the effect of this change is to avoid work in one special case. Assume we have copied the binary and sources to /path/to/product/bindir and hence have the sources in /path/to/product/bindir/my/configured/sourcedir. With the old config the debugger will never find the sources automatically. We have to configure the source search path to /path/to/product/bindir/my/configured/sourcedir. With the new config it will find the sources automatically in the special case that we run the debugger with /path/to/product/bindir as the working dir for the debug session. It's not normal to login and debug a binary in the installed dir for obvious reasons. Of course it is simple to switch the debugger working dir to the bin path but it is equally simple to set a source search path.
So, I don't see this change as actually being of much help for production debug but I think it is going to add an extra step for debug during development.
FTR: "Previously" being after the 21.1 release, in 20.3 and 21.0 we were still using relative paths.
TBH I am not qualified to argue about this :) So it seems like it all boils down to "what's more common?". I really don't have answers for that questions so I welcome any feedback :) Given that users who are going to chase down bugs through gdb are expected to be fairly advanced, I can see how this PR might not be of much help. @olpaw if you agree with the above (including Andrew's comments) I am going to close this issue. |
From my experience this is rarely the case. If possible you always try first to replicate the issue locally (in your cosy dev environment) instead of debugging in the production environment. Most of the time this is possible and has the advantage that you can rebuild the ill-behaving artifact, try things out and to use different flags for better debugging experience (e.g.
Dev machines 99% of the time.
Yes. Unfortunately this happens rather often. E.g. if you build a native-image shared library that gets loaded by some other C/C++ framework you often do not have the luxury to have the cwd set to the build-target directory of that particular image.
The person that runs an image (to achieve something ... aka the user) is rarely the person that is able to debug that image if it fails. The user consults the dev and that's then the person in charge for debugging it (at least in my experience).
Yes please close the issue. |
|
Thank you for the feedback Andrew and Paul! |
As if 21.1 (oracle/graal@dee66ca) dwarf info contain absolute paths to the source-cache. As a result moving the sources breaks gdb. The move was performed to make sure the sources are next to the binary, in an effort to ease debugging on remote hosts by copying the binary and the sources in the same directory. As discussed in oracle/graal#3828 this is not expected to be the common case, so it's better to favour the local debugging experience by leaving the sources where they were placed by GraalVM/Mandrel.
As if 21.1 (oracle/graal@dee66ca) dwarf info contain absolute paths to the source-cache. As a result moving the sources breaks gdb. The move was performed to make sure the sources are next to the binary, in an effort to ease debugging on remote hosts by copying the binary and the sources in the same directory. As discussed in oracle/graal#3828 this is not expected to be the common case, so it's better to favour the local debugging experience by leaving the sources where they were placed by GraalVM/Mandrel. (cherry picked from commit db5ad51)
As if 21.1 (oracle/graal@dee66ca) dwarf info contain absolute paths to the source-cache. As a result moving the sources breaks gdb. The move was performed to make sure the sources are next to the binary, in an effort to ease debugging on remote hosts by copying the binary and the sources in the same directory. As discussed in oracle/graal#3828 this is not expected to be the common case, so it's better to favour the local debugging experience by leaving the sources where they were placed by GraalVM/Mandrel. (cherry picked from commit db5ad51)
As if 21.1 (oracle/graal@dee66ca) dwarf info contain absolute paths to the source-cache. As a result moving the sources breaks gdb. The move was performed to make sure the sources are next to the binary, in an effort to ease debugging on remote hosts by copying the binary and the sources in the same directory. As discussed in oracle/graal#3828 this is not expected to be the common case, so it's better to favour the local debugging experience by leaving the sources where they were placed by GraalVM/Mandrel. (cherry picked from commit db5ad51)
dee66ca started enforcing the use of
absolute paths in DW_AT_comp_dir which results in the following issue.
After compilation is done and one wants to debug their binary on their
deployment machine they will need to transfer both the binary and the
sources directory. As a result any absolute paths in the dwarf info will
now be invalid. However, if the sources directory are kept in the expected
relative-to-the-binary path, a relative DW_AT_comp_dir will remain valid
and gdb (as well as other tools) will be able to pick the sources up
without any additional configuration (e.g.
directory path/to/sources/in gdb.
Closes: quarkusio/quarkus#20321