Author doesn't mention Nix by name, so I wonder if they're aware of it. While it as a build system has more than its fair share of "dark corners", it does solve the reproducibility of all paths (including with a chroot, to get fixed-length paths), and has automagic debuginfod support via [1].<p>[1]: <a href="https://github.com/symphorien/nixseparatedebuginfod">https://github.com/symphorien/nixseparatedebuginfod</a>
This is definitely a hack and despite their claims that it's more robust they've introduced a load of more failure modes.<p>I can't imagine it's really that slow to edit the paths properly. It's probably just accidental N^2 or something.<p>Also it feels like there should be a proper field in ELF/DWARF for this if people are wanting to do it a lot (and it seems like a reasonable thing to do).
__FILE__ is pain of my existence, recently contributed this code to run/build ds3os using nix instead of docker, where I hit issues with __FILE__<p><a href="https://github.com/TLeonardUK/ds3os/blob/main/default.nix#L41-L45">https://github.com/TLeonardUK/ds3os/blob/main/default.nix#L4...</a>
I am kinda struggling to understand the proposed solution. So, okay, I have an EXE, and I have a PDB file for it, and that PDB file states that the source code lived at the Q:\Users\raymond.chen\Documents\work\projects\ContosoFoobar\src\main.c. Instead of having some sort of debugger setting to allow me to remap the path to something existing on my machine (my disks go up only to H:, for once), the proposed solution is to monkey-patch the PDB file itself. But, like, why? It doesn't solve the main problem that you still need to somehow find the sources, manually.<p>Also: if you really, really want to never go looking for the sources ― just store them in the finished executable/debug info file. Seriously. For some reason, they're (when gzip'ed) somehow smaller than the resulting executable with debug info.
The premise of the tool seems very useful: edit debug symbols and assert messages so that source code can be found by debuggers. But this description does not make it clear how this tool accomplishes the whole task:<p>> Why not fix the binary coming out of the build cache, so it points to the absolute path of the source files?<p>What is the absolute path? If you had a virtual file system that allowed you to construct a path to any file at a given commit, this would work great. But who does that other than Google? Or if you agree that every developer will check out the same source code repo at the same path, but the you have to have the right commit checked out.<p>Ideally you would want your binary to point back to your code repo, like SourceLink does.<p><a href="https://github.com/dotnet/sourcelink">https://github.com/dotnet/sourcelink</a>
> firstly, GNU memmem is slower than memchr::memmem::Finder,<p>Not only slower than the rust version, also slower than most other >200 string search functions. Whilst musl has the fastest string search function for less than 32 substring chars.<p>See <a href="https://rurban.github.io/smart/results/all/rand2.html" rel="nofollow">https://rurban.github.io/smart/results/all/rand2.html</a> with libc1 being GNU libc memmem() and musl1 being musl's memmem().
Weird post. It raises questions, then admonishes you for reading them.<p>> "Well you're not supposed to get core dumps from versions with uncommitted changes, unless it's your local version that you haven't given to anyone but are testing locally, so you know which version it is. You should only release versions externally thru CI" - so giving anything to anyone to test is now considered "releasing externally" and must necessarily go thru CI, and having trouble finding the source code is now a punishment for straying from proper procedure? How did this discussion, which started at how build caches speed up the build, deteriorate to the point where we're telling developers to change how they work, in ways which will slow them down?<p>Hey, you brought it up. Don't put this on the reader.
The author is much too self deprecating! IMHO this isn’t the dreaded “premature optimization,” it’s avoiding pessimization. I’d like to read them in their unrestricted voice!<p>Great article!
Just for the record, for nicer inspection of files with such debug information, including compressed sections, and debuginfod support, Rizin[1] can be used, since starting from the 0.7.0 release[2] all of those were added.<p>[1] <a href="https://rizin.re" rel="nofollow">https://rizin.re</a><p>[2] <a href="https://github.com/rizinorg/rizin/releases/tag/v0.7.0">https://github.com/rizinorg/rizin/releases/tag/v0.7.0</a>
Refix proposes an intriguing approach to achieving fast, debuggable, and reproducible builds - a triad often considered difficult to attain simultaneously. Its methodology, emphasizing minimal binary manipulation to preserve debuggability while ensuring reproducibility, introduces a potentially game-changing technique in software development practices. However, the practicality of implementing Refix in diverse development environments, especially those with complex dependency graphs and varying build processes, raises some concerns. Additionally, while the focus on C/C++ is understandable given the language's compilation model, the broader applicability to other programming paradigms remains to be seen. The proposition of modifying binaries post-compilation might also introduce unforeseen complexities in continuous integration workflows. Refix's novel idea undoubtedly sparks interest, but its adaptation to the multifaceted landscape of build systems calls for a thorough examination of its implications and integrations.