3 ms·

although not the target audience of tfa (no build caching, because we have a compact c codebase), we always use relative paths in compiler invocation, and that

by 5- 3y ago

although not the target audience of tfa (no build caching, because we have a compact c codebase), we always use relative paths in compiler invocation, and that naturally results in relative paths in debug info. so we've never had the problem the author set to resolve -- despite each of us (and the ci) having different source tree locations, gdb picks up the source code just fine. i guess build systems people use love canonicalising source paths?

yosefk 3y ago
Actually you very much do have the problem I set to resolve :-) in the sense that if you get 5 core dumps from 5 program versions, you don't know which source tree corresponds to which core dump. You might not experience this as a problem because there's some way of finding the source tree, but you definitely have it :-) Note that in general, relative paths create 2 problems: 1. You [and tools] don't know where the code is just by inspecting the binary; 2. There may be more than one answer to the question relative to what? In this sense, a relative path is potentially even worse than "an absolute path to a directory created during the build that was since deleted", since there's substitute-path [in gdb, not necessarily any other DWARF consumer, but at least in gdb] and you could find currently existing paths corresponding to the absolute paths in the build and remap them (unless of course they were all the same absolute path like /tmp/xxx but they were directories on different build hosts or created at different build phases - but you hope it won't get this bad.) With relative paths, you have no reasonable way of remapping different meanings of "./" to different absolute paths since "./" is always "./" (though you might remap differently based on what follows "./" in the path; but it's getting really painful at this point.) This "relative to what"? question is not a problem if you have a monolithic build (which is awesome, everyone should!) with all the source kept under the same root directory and then "relative to what?" has the sane single answer "relatively to that root directory." This can be a big problem if there are multiple build systems building multiple binaries in different root directories and a linker then links those libraries or they're shared objects loaded at runtime and ending up in the same process or core dump.
- beeboobaa3 3y ago
  > 1. You [and tools] don't know where the code is just by inspecting the binary; Your bug reporting tool should obviously report the version of the software the dump is associated with. It's common to just put the git hash in the binary. > 2. There may be more than one answer to the question relative to what? The directory CI runs in. If you're not sure, check your CI scripts.
  - yosefk 3y ago
    1. What if the version has uncommitted changes? What if the code is compiled from multiple repositories? I should now clone them all? 2. As discussed in GP, there can be more than one such directory if your build isn't monolithic (which it should be, but it often isn't)
    - beeboobaa3 3y ago
      > What if the version has uncommitted changes How is knowing the filenames going to help with that? > What if the code is compiled from multiple repositories? I should now clone them all? Presumably you already have a CI script that does this. If not, invest a few minutes into making one.
      - yosefk 3y ago
        If the code has uncommitted changes they are typically (~always) kept in the modified files they were compiled from. Knowing the filenames is how you find them.
        beeboobaa3 3y ago
        Great, I now have the path to my git repository, same as every other build, and probably leaked my system username in the process.
  - runiq 3y ago
    That has been addressed in TFA: https://yosefk.com/blog/refix-fast-debuggable-reproducible-builds.html#why-do-this-we-already-have-a-system-for-finding-the-source-code https://yosefk.com/blog/refix-fast-debuggable-reproducible-b....

by 5- 3y ago

yosefk 3y ago

Actually you very much do have the problem I set to resolve :-) in the sense that if you get 5 core dumps from 5 program versions, you don't know which source tree corresponds to which core dump. You might not experience this as a problem because there's some way of finding the source tree, but you definitely have it :-) Note that in general, relative paths create 2 problems: 1. You [and tools] don't know where the code is just by inspecting the binary; 2. There may be more than one answer to the question relative to what? In this sense, a relative path is potentially even worse than "an absolute path to a directory created during the build that was since deleted", since there's substitute-path [in gdb, not necessarily any other DWARF consumer, but at least in gdb] and you could find currently existing paths corresponding to the absolute paths in the build and remap them (unless of course they were all the same absolute path like /tmp/xxx but they were directories on different build hosts or created at different build phases - but you hope it won't get this bad.) With relative paths, you have no reasonable way of remapping different meanings of "./" to different absolute paths since "./" is always "./" (though you might remap differently based on what follows "./" in the path; but it's getting really painful at this point.) This "relative to what"? question is not a problem if you have a monolithic build (which is awesome, everyone should!) with all the source kept under the same root directory and then "relative to what?" has the sane single answer "relatively to that root directory." This can be a big problem if there are multiple build systems building multiple binaries in different root directories and a linker then links those libraries or they're shared objects loaded at runtime and ending up in the same process or core dump.

beeboobaa3 3y ago
> 1. You [and tools] don't know where the code is just by inspecting the binary; Your bug reporting tool should obviously report the version of the software the dump is associated with. It's common to just put the git hash in the binary. > 2. There may be more than one answer to the question relative to what? The directory CI runs in. If you're not sure, check your CI scripts.
- yosefk 3y ago
  1. What if the version has uncommitted changes? What if the code is compiled from multiple repositories? I should now clone them all? 2. As discussed in GP, there can be more than one such directory if your build isn't monolithic (which it should be, but it often isn't)
  - beeboobaa3 3y ago
    > What if the version has uncommitted changes How is knowing the filenames going to help with that? > What if the code is compiled from multiple repositories? I should now clone them all? Presumably you already have a CI script that does this. If not, invest a few minutes into making one.
    - yosefk 3y ago
      If the code has uncommitted changes they are typically (~always) kept in the modified files they were compiled from. Knowing the filenames is how you find them.
      - beeboobaa3 3y ago
        Great, I now have the path to my git repository, same as every other build, and probably leaked my system username in the process.
- runiq 3y ago
  That has been addressed in TFA: https://yosefk.com/blog/refix-fast-debuggable-reproducible-builds.html#why-do-this-we-already-have-a-system-for-finding-the-source-code https://yosefk.com/blog/refix-fast-debuggable-reproducible-b....