Hi Mark, Valgrind is definitely on my upstreaming list, alongside GDB, LLDB and Linux perf.
You can see the preliminary version here: https://gist.github.com/eddyb/c41a69378750a433767cf53fe2316768 (do not use it yet, I still want to tweak it a bit more before upstreaming it, soon, and I want it to go through the GCC/GDB review process). You'll be able to either modify it, to replace the malloc/realloc/free calls, or use rust_demangle_with_callback and use your own buffer (or directly print the demangling, if that's all you need). Feel free to contact me outside of this list, at this email or on IRC (eddyb on Freenode and OFTC), if you want to further discuss the details of upstreaming the new demangler to Valgrind. - Eddy B. On Tue, Jun 4, 2019, at 11:29 AM, Mark Wielaard wrote: > On Sat, 2019-06-01 at 17:14 +0300, Eduard-Mihai Burtescu wrote: > > When libiberty/rust-demangle.c was initially added, its two exports, > > rust_is_mangled and rust_demangle_sym, made it to include/demangle.h. > > However, these two functions are merely implementation details of > > cplus_demangle and rust_demangle, only the latter should be public. > > > > This is becoming a problem, because the new Rust mangling scheme > > does not fit this "postprocess after C++ demangling" API at all, > > so rust_demangle_sym would forever be stuck supporting only the > > legacy mangling, whereas rust_demangle can easily handle both > > (the new version of which I plan to upstream soon). > > > > I'm hoping that libiberty doesn't have strict backwards-compat > > requirements, so that we can hide these two functions. > > Also, as far as I'm aware, nobody is using them in the wild. > > valgrind uses an embedded copy of the libiberty demangler (slightly > changed to use valgrind's internal memory allocation scheme) which does > use these functions directly: > > https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_demangle/demangle.c;hb=HEAD#l153 > But we could of course just include the "private" header instead, when > we next sync up with libiberty. > > We use these functions directly precisely because the rust demangling > scheme is (currently) based on top of the traditional _Z C++ demangling > scheme and we know that it will be done "in place". If there is a new > Rust demangling scheme that doesn't have that property we'll have to > adopt to a different demangling scheme in the future. Any help with > that appreciated. valgrind has been useful for combined c/c++/rust > programs. > > Cheers, > > Mark >
