Skip to content

debug info: resolve relative paths to source files into absolute paths #13843

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Dec 9, 2022

Conversation

kubkon
Copy link
Member

@kubkon kubkon commented Dec 9, 2022

This change brings back stage1 behavior in that all debug info paths that are emitted in DWARF/PDB are always absolute. Note that the paths are resolved only when committing them into either a respective LLVM type (llvm.DIFile), or when emitting DWARF (as is the case with self-hosted backends).

This change will make stack traces and debugging experience more consistent in the sense that the presence of source lines in stack traces will not be dependent on the current working directory of the running process, making cases like #13831 non-existent (I am referring here to lack of source lines in submitted stack trace, not the actual linker bug which is unrelated).

Additional bonus is that we no longer need to mess with lld-links output on Windows by including special PDB path manipulating flag, -PDBSOURCEPATH as all source paths are now absolute by design.

Finally, as generating valid debug info output is important but not critical, if a call to std.os.realpath fails for whatever reason, we simply fallback to relative paths readily available.

If we merge this, this patch will obsolete #13540

cc @Vexu

This will make stack traces and debugging experience more consistent
in the sense that the presence of source lines in stack traces will
not be dependent on the current working directory of the running process.
@kubkon kubkon changed the title Resolve relative paths to source files into absolute paths debug info: resolve relative paths to source files into absolute paths Dec 9, 2022
@kubkon kubkon enabled auto-merge December 9, 2022 17:52
@kubkon kubkon merged commit bd5a8f8 into master Dec 9, 2022
@kubkon kubkon deleted the dwarf-abs-paths branch December 9, 2022 18:18
@squeek502
Copy link
Collaborator

Unless I'm mistaken, this will cause a compile error on some BSDs (see #13565, #13699).

@kubkon
Copy link
Member Author

kubkon commented Dec 9, 2022

Unless I'm mistaken, this will cause a compile error on some BSDs (see #13565, #13699).

Happy to accept a patch that avoids realpath on those hosts. Also, please note that this is also a problem if anyone wants to crosscompile to macOS from some BSDs as we also use that primitive there. In the meantime, this is the only sane default I can think of for Linux, macOS and Windows hosts.

@semarie
Copy link
Contributor

semarie commented Dec 10, 2022

realpath is only problematic when using std.fs.realpath() and not when using std.os.realpath(), so it is fine

@kubkon
Copy link
Member Author

kubkon commented Dec 10, 2022

realpath is only problematic when using std.fs.realpath() and not when using std.os.realpath(), so it is fine

Do you mean std.fs.Dir.realpath() perhaps? Is that since it calls std.os.getFdPath() which seems to be supported by FreeBSD but not other flavours?

@semarie
Copy link
Contributor

semarie commented Dec 10, 2022

yes, std.fs.Dir.realpath() (sorry for the confusion). and yes, due to std.os.getFdPath() which isn't widely supported

@squeek502
Copy link
Collaborator

Thanks for clearing that up @semarie!

@andrewrk
Copy link
Member

Follow-up issue: #16571

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants