ghidra
ghidra copied to clipboard
NationalSecurityAgency
Show all symbols for a given address in the listing
Is your feature request related to a problem? Please describe. Is it possible to show all matching symbols in the listing for the relevant address? There are several cases where it can be useful, sometimes the optimizer uses the same implementation for several functions, but several symbols still point to it. Ghidra only chooses one of them.
Describe the solution you'd like Show all symbols for that address, see screenshot below.
Describe alternatives you've considered I can use the Symbol Table, but it's much less convenient.
Additional context
As you may be aware, all of the mangled symbols known by Ghidra are listed in the symbols section (where cursor is in the picture). Are you asking for each mangled symbol to have its info also added to function header?
Yes, and I'm fact, also in the decompiler, that would be useful.
On Mon, Aug 1, 2022, 20:30 dragonmacher @.***> wrote:
As you may be aware, all of the mangled symbols known by Ghidra are listed in the symbols section (where cursor is in the picture). Are you asking for each mangled symbol to have its info also added to function header?
— Reply to this email directly, view it on GitHub https://github.com/NationalSecurityAgency/ghidra/issues/4494#issuecomment-1201502861, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMDRPHF6C2VXM4KWMPU4WLVXACULANCNFSM55IBZVOQ . You are receiving this because you authored the thread.Message ID: @.***>
Yes, and I'm fact, also in the decompiler, that would be useful.
Personally I would prefer less noise instead of more.
Yes, and I'm fact, also in the decompiler, that would be useful.
Personally I would prefer less noise instead of more.
I've spoken with @dragonmacher numerous times about this topic, as that is also my concern. In the simple case, it probably wouldn't matter much, but even though I've wanted to see the various demanglings of symbols in the plate comment, my concern has kept me from implementing this long ago. One of my research areas is to try to deal with the numerous symbols that can be found at one address better (discussion with you regarding template processing)(@justanotheranonymoususer this is the "sophsiticated" comment I made in #4489). Sometimes they are related, such as shared code for template methods, but there are also times that it comes about due to COMDAT folding. I've worked on some binaries in which there are thousands of symbols on functions. The symbols alone cause noise, but then to add thousands more lines of plate comment makes it worse. I've also broached the topic of a "smart" plate comment, but I don't want to go too much into that discussion here.
Hmm, maybe we can make the comment collapsed by default, saying something like:
/*
int f1();
4 additional symbols referring to the same address:
(collapsed)
*/
Then, clicking on "(collapsed)" or on an arrow or "+" on the left will expand the collapsed comments.
Something like intellij imports maybe:
I agree that without the collapse, it is probably going to lead to a lot of noise - especially when every free/return zero/increase ref count etc. function is mapped to the same location, you really do not want to see hundreds of lines popping up in your decompiler output.
On a separate note, it might be a useful feature to be able to select which symbol is being called from the caller side. In this example, being able to right click the call to ref and set it to B::ref would improve the quality of the decompiler output.
// (A::ref, B::ref, C::ref)
void A::ref(A * this) {
this->field_0++;
}
void B::doSomething(B * this) {
A::ref((A*)this);
}
This would be even better if we allow for 'shadow' function prototypes which can be interacted with from the UI i.e. at the address of A::ref, B::ref and C::ref can have prototypes void ref(B*) and void ref(C*) respectively, so that overrides immediately take on the correct prototype (and also change when the prototype of the shadow functions are changed). That being said the regular call override should suffice for the 'call symbol override' feature to be useful out of the box.
Perhaps some mechanism similar to switch overrides could work? If there is appetite for this feature I will make a separate FR for it.
Another place where such symbols are missing is the symbol tree. It's actually kinda confusing. I'd expect all symbols to be displayed there and if several symbols point to the same address, they can have the same on-click action.
@justanotheranonymoususer Did you try the DemangleAllScript? I believe that will demangle all symbols, even the secondary ones. If you want to just demangle one at a time, you can click on any label, even secondary ones, and run DemangleSymbolScript instead.
I didn't try. I'll try, but that sounds like a hassle, equivalent to opening WinDbg and using it for that. That's what I've been doing a couple of times. It works, but the experience can be improved.
I didn't try. I'll try, but that sounds like a hassle, equivalent to opening WinDbg and using it for that. That's what I've been doing a couple of times. It works, but the experience can be improved.
I agree but it would be a workaround until the demangler is updated to work on more than just one symbol per address, which apparently is not going to be easy given how it was originally designed. Running the DemangleAllScript once per binary wouldn't be too bad.
Also, you can assign keybindings to scripts to make them quicker to use.
@ghidra007 I finally tried the DemangleAllScript, but it seems like nothing changed. It took it a while to run, and it printed some symbols which it was unable to process, but after it's completed, where I can see the result? What does it change?
@justanotheranonymoususer It should have demangled any secondary symbols at addresses where there already is a demangled symbol. I agree it spits out a bit too much info -- it tries all symbols and if not mangled it says it can't process. So any that were already processed before you ran the script and any that are not mangled to begin with would listed as "unable to process".