Thank you!
#664
Replies: 2 comments
-
Thanks for the feedback! It's very encouraging to hear that it's useful and working well. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I'm glad you found them useful. I make extensive use of I look forward to reading the long-form blog post about the success of your Rewrite It In Rust project. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi all! I just want to drop you a huge "thank you" for creating the various gimli projects. I can honestly say that I have rarely had the pleasure of using software that at the same time solves such a complex problem and works so flawlessly as
object
,gimli
andcpp_demangle
.At Elastic we are building a system wide profiler. Because stack traces with just addresses are pretty boring to look at and production systems tend to not have debug symbols on disk, we built a tool that allows users to extract ELF VA <-> inline trace mappings from executables in their CI/CD pipeline and to push them to the profiling deployment. Additionally, because no one wants to manually push symbols for all the OS packages that tend to power the world but aren't the user's own executables, we maintain a public service where we crawl, mirror, and create symbol mapping files for all executables of all packages of all channels for a selection of major Linux distributions. This includes both current and historic package versions dating back to 2019 for both amd64 and aarch64.
Our first iteration of this conversion tool was written in Go, using the
debug/elf
+debug/dwarf
packages. We have spent a pretty significant amount of time on workarounds and quirks for edge cases that would stop these libraries from running into pathological performance, straight up incorrect parsing or unbounded allocs that would send us into OOM. Even if things did work out, performance ranged between "not great" for average binaries and "absolutely atrocious" for hostile binaries like Firefox libxul.so (>1 hour to just walk the DWARF tree once). After a lot of banging heads against walls, we decided to cut our losses and rewrite the component in Rust.We have now parsed through 45TiB of (compressed!) packages in record time and haven't had a single significant issue1. Needless to say there are a lot of packages with broken DWARF (about 1%), but for all the samples that we investigated it turned out to be genuinely broken DWARF as a result of linker bugs. A lot of these broken objects just straight up SIGSEG llvm-dwarfdump and GNU objdump. Not a single gimli bug found. Performance is orders of magnitude better than with the Go tooling. The largely copy-free API is designed in a way that allows us to keep almost all allocations bounded. All the nice newtypes for the various offset variants make it really hard to shoot yourself in the foot. Documentation is awesome.
Honestly we just couldn't be any happier: this is just an absolutely magnificent piece of software. Thanks a ton for your dedication and work on this: it really shows.
Footnotes
There was one executable that ran into pathological performance in
cpp_demangle
, but @khuey fixed it in record time. ↩Beta Was this translation helpful? Give feedback.
All reactions