3 ms·

What about debuginfod instead? Look up your source and even your debug symbols by your build identifier.

• yosefk 3y ago
  debuginfod is infinitely better than nothing, but I think much worse than the binary just pointing to the absolute source path (1). Using debuginfod for this is an example of what I meant by "people standardizing on workarounds" to a problem which I think is more easily solved by "refixing" the binary to the absolute path. Some issues with debuginfod you won't have with "refixed" binaries: * If an assert fails, you still don't get an absolute path you can open in an editor in the error message * This assumes the debug info including the source code was uploaded to the server. This can work for "external releases" but do you want this to happen with every build done by every user? This would be notably slower than refixing the binary. If you don't do this, then for every build you didn't do this for, you still have the problem * Not all tools consuming DWARF support this. gdb and Valgrind do; does VTune or the sanitizers which emit call stacks with source lines you then want to open in an editor? * Implementing this reasonably is just much more work than passing 2 flags to gcc and running one post-link pass on every binary coming out of the build system (1) Well, "much worse" in this specific sense. debuginfod does solve a different problem of distributing debug information to people who have a binary installation without debug info on demand. At this it's infinitely better than refix which doesn't help here at all. However this is not how I'd like to work on my employer's software as a developer.