-
-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Demangle Rust symbols #371
Comments
LLVM has something named RustDemangle.cpp, in case that helps. Don't know how complete it is, though. Nor how stable its API is. AFAIK LLVM offers no stability guarantees other than their C API (which only exports a subset of functionality), but Another option would be tossing a C-compatible API onto rustc-demangle and calling that. This has the drawback that mold needs rustc nearby to demangle Rust symbols, but the advantage that there's no need to wait for the alternate demangler to update if Rust starts doing something new (C++ lambdas took a while to be demangled correctly). |
I don't want to depend on LLVM nor rustc, so I was thinking of implementing it ourselves. It looks like it's not too hard to write our own implementation. |
GNU libiberty (as used by binutils and gdb) has support for demangling both the current legacy symbol mangling scheme and the new v0 symbol mangling scheme. In any case if you want to implement it yourself the v0 symbol mangling scheme is documented at https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html |
If there's still interest in implementing this ourselves, I'd be interested in giving it a try. I looked over the RFC linked above and it seems doable. If that sounds alright, I'm just wondering what approach to take for writing the new demangler. I was thinking of either writing a new Rust demangling function in Thanks in advance! |
The current situation isn't as bad as I originally thought when I filed this bug. I misunderstood that the new mangling scheme is already in use, but in fact, Rust seems to be still using the old modified Itanium mangling scheme, and that can be demangled fairly well with the existing C++ demangler. We need to support the new Rust mangling scheme eventually if Rust will eventually switch to that scheme, though. Does anyone have any idea when that will happen? @a-lafrance
|
Interesting, makes sense. In that case, if you're looking for help with that new demangler project, I'd be interested. |
Indeed.
You can already opt in on stable. All blockers towards switching to it by default seem to have been resolved so we may switch the default soonish: rust-lang/rust#60705 (comment) After that it takes between 6 and 12 weeks before the change lands on stable depending on where in the release cycle we switch. |
@a-lafrance Feel free to start a project. If you start it, it'll be your project, and not only mold but other projects will find it useful. |
@rui314 Sounds good, I'll give it a try then. I'll revisit this thread when I have something to show for it I guess. |
This would be the fourth non-Rust demangler for Rust (libiberty, IllumOS, LLVM off the top of my head). I would suggest reusing the libiberty one (that I wrote - let me know what you need from me to re-license it, surely I am not limited to GPL just because I contributed it to the GCC repo?), or the LLVM one if its license is agreeable. AFAIK both are ports of the Rust code, though in different styles. The former has been used in several other projects, and it was supposed to be a self-contained single-file demangler implemented in C from the start, that everyone used, but perhaps we failed on the messaging front. |
I wasn't aware that there are already multiple implementations for demangling Rust symbols. Let me take a look. As to the one in the libiberty, I think you can relicense it unless you assign its copyright to GNU, but until the last year, GNU project had required all contributors to assign copyright to them, so the code you wrote may no longer be owned by you. If the Rust demangler in libiberty were in its own repo and can be compiled to a simple command that just demangles a mangled symbol, it would have been much easier for me to find. |
https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf
If I understand correctly @eddyb could still relicense it under any license, the FSF would just be the copyright holder. |
I'm not a lawyer, but I don't think you can (re-)license software as you want unless you have the copyright of that software. You can still ask the current owner of the software to relicense, though. |
As I understand it they give you a license back that allows you to sublicense it under any terms you want. I can't easily find the exact legal text though. |
@bjorn3 Ah, I missed that point. I think you are right. |
I agree - upstreaming (to allow e.g. gdb and valgrind to work), was the main priority (and delayed stabilization by a lot, because it turned out to be messier than we hoped) but we should've made it more reusable from the start. I'm not sure where it should go, the problem with putting it in One version of it has been in a gist (w/ a small test driver, which compares output against
I'll have to check, I don't remember being put through that, but it's possible they only didn't require it for the first few (smaller) refactor patches - either way, pretty big blunder on my part if I went with it just "to get it done". |
alternative: https://github.com/getsentry/symbolic/blob/master/symbolic-demangle |
That is a rust crate which uses the rustc_demangle crate for demangling rust symbols: https://github.com/getsentry/symbolic/blob/56349e9686a4dc655d0b9e9c0ccfff82ca4e95d7/symbolic-demangle/src/lib.rs#L278 |
Damn it! At times forget about these interdependencies. 😅 |
(Sorry for not getting back to this in the past month, other things kept coming up etc.) So I just took a look over the emails for my libiberty contributions, and at no point did anyone even mention copyright assignment, and I never signed anything, so unless it's implicit without a signature, I'm in the clear. The plan right now is to take the gist history and turn it into a repo, but cut it off short (just before I integrated the existing libiberty code), and reimplement the relevant missing features (legacy symbols, some of the constants, etc.) based on the Rust code in |
@eddyb Sounds great! Once the repo is ready, I'll try to integrate it into mold. |
Finally got around to setting up that repo I kept promising: However, I ran out of time this weekend to actually implement anything new, and only got around to writing the (FWIW, for The public API is declared entirely in the tiny #define RUST_DEMANGLE_FLAG_VERBOSE 1
bool rust_demangle_with_callback(
const char *mangled, int flags,
void (*callback)(const char *data, size_t len, void *opaque), void *opaque
);
char *rust_demangle(const char *mangled, int flags); I don't expect this to change (other than adding flags for e.g. controlling recursion/output limits), unless there's demand for additional features that can't be expressed through it. So feel free to leave any feedback (ideally as issues on that repo) on that side of the design. As for all the missing features, I'll get back when I get more time to port them. |
Thank you very much for @eddyb for doing this! I integrated your Rust demangler in the above commit, though I haven't tested it yet. |
Oof, C++ compat (0e88fd0) definitely is something I should've handled (thought of it but then forgot). But I don't think it's going to work within the Looking at the commit history, seems like |
Is there any regression from the C++ users's point of view if we attempt to demangle a string as a Rust mangled name before as a C++ mangled name? If a valid C++ mangled name is demangled as a Rust mangled name in an weird way, we can't call Updating a subtree is easy; it should be updatable with a |
No regression AFAIK, and this is what
So the way As an example, It's unfortunate that they're not more distinct, but I haven't heard of a C++ symbol being mistaken for one yet. |
Thanks. I made a change so that symbols are demangled as Rust symbols before as C++ symbols. I'll test this change tomorrow. |
Rizin also implemented Rust demangling in pure C in the universal demangling library - rz-libdemangle, it's under LGPLv3 license (except C++ demangling for now: rizinorg/rz-libdemangle#3) |
Currently, we demangle only C++ symbols, but we should be able to demangle (i.e. pretty print) mangled Rust symbols.
Unfortunately, it looks like there's no C++ library that can demangle Rust symbols. Maybe we need to rewrite https://github.com/rust-lang/rustc-demangle in C++.
Note that this is not high priority.
The text was updated successfully, but these errors were encountered: