"A load of more failure modes" - which? This has been used for more than a year by more than 1000 developers and there were never complains about corrupted bina

"A load of more failure modes" - which? This has been used for more than a year by more than 1000 developers and there were never complains about corrupted binaries or corrupted debug information (except when for some reason "refixing" didn't actually happen for some of binaries), or build speed issues. This, in a code base producing a binary that crashed debugedit after 30 seconds of processing. So empirically it's fine and I think also fine on theoretical grounds; if you disagree it'd be interesting to hear the details. Regarding replacing the paths "properly": it's not accidentally quadratic, it's predictably linear but with large constants because there's a lot of data to move and a lot of offsets to update. An example of such a problem (linear complexity, large constants) is the linker. It took more than 40 years for C++ linkers to get fast; mold is the linker that I always said was possible (a very fast one) but that I didn't actually implement. Now it's implemented and it takes 5-10 seconds to link that large binary. This is roughly the speed that you can hope for if you not only postulate the possibility of fast DWARF editing like I used to do with fast linking but actually implement it; this will still be an order of magnitude at least slower than refix but it will match the speed of sed. Of course since we had to wait for more than 40 years for a fast linker and a linker is something nobody can do without and everyone wants to be fast, we will have to wait for more like 400 years for anyone to actually optimize debugedit to that level. And I much prefer the small annoyance of having leading ////// in the file paths to waiting for 400 years for a less buggy and faster debugedit and then waiting 5-10 seconds per rebuild. I agree that it would have been great if the DWARF format as well the actual DWARF producer made it easier to change path prefixes, and it'd be especially great if it worked with compressed debug sections without having to uncompress and recompress them.