Variety of errors after DemangleAllScript.java on EXE loaded with MAP file

[Joey35233]

Ah, I did not. Just ran DemangleAllScript.java - still doesn't work quite right. Many are okay but there are some issues:

Many globals did not change despite the yellow-tan text indicating it can be demangled with no problems:

Some were correctly demangled but their parameters don't have type information (but somehow do in the Listing view?)

A final group seems to get confused with other symbols.

If this moving off-topic I can move to a new Issue.

Originally posted by @Joey35233 in #7945

After receiving help with a fix for the map loader code, I re-Add[ed] to Program the map file and subsequently ran DemangleAllScript. However many symbols either weren't demangled, do not display type information in the Decompiler, or have unexpected conflicts with other, non-overlapping symbols.

[dragonmacher]

Ghidra's demangling system is done via an analyzer. That analyzer does much more than the given script does. Have you tried ru-running the analyzer?

[Joey35233]

I'm sorry, I should have mentioned: before I used DemangleAllScript.java I tried One Shot > Demangle Microsoft and that actually did very little - that's what I thought at the time, although my results below suggest that it actually does the same as DemangleAllScript.java.

Anyway, following your suggestion I reset the project, re-added the MAP, then ran the full Analysis again. Unfortunately no change. It seems like there is some genuine issue with demangled symbols being applied. The following are my three sentinel examples above after running this process:

First example - still no demangling of any of these symbols.

Second example - still no types for the params.

Still inappropriate overlapping with the RTTI type descriptor above.

[dragonmacher]

I may be confused about what I'm seeing here. It appears that the labels are correctly demangled in the Listing view. We keep the new symbol and the original mangled symbol.

It looks like the issue is that the primary label at each address is the original mangled symbol and not the demangled version. When the demangled symbols are applied, the newly demangled symbol will be made primary. But, they may not do this if the existing primary symbol has been changed by the user somehow. The decompiler is using the primary label at a given address, which is why it is showing the mangled symbol.

In this example, you can see the primary symbol in blue (the mangled symbol) and the demangled symbol above it in gold.

[Joey35233]

Ah, sorry, I didn't know that terminology. With that in mind, I think you're right that the proper issue description is that the _primary_ labels remain mangled, yeah. I have not changed the labels pictures but there is an unusual background: Ryan fixed a bug that meant Ghidra was skipping over large parts of the map file - the issues are with the _new_ symbols that came along after that fix. I also did change my Ghidra version between now and three months ago when I applied the map file (which I didn't realize was only partially applied) for the first time. In short, I can definitely believe that a combination of updating the Ghidra project database and re-applying the map could make the demangler think the labels were user-modified. Is there any way to force apply all of MAP-derived labels?

…

On Thu, Mar 27, 2025, 19:28 dragonmacher ***@***.***> wrote: I may be confused about what I'm seeing here. It appears that the labels are correctly demangled in the Listing view. We keep the new symbol and the original mangled symbol. It looks like the issue is that the primary label at each address is the original mangled symbol and not the demangled version. When the demangled symbols are applied, the newly demangled symbol will be made primary. But, they may not do this if the existing primary symbol has been changed by the user somehow. The decompiler is using the primary label at a given address, which is why it is showing the mangled symbol. In this example, you can see the primary symbol in blue (the mangled symbol) and the demangled symbol above it in gold. image.png (view on web) <https://github.com/user-attachments/assets/52af0f2d-ec1a-49eb-aa02-e28558211734> — Reply to this email directly, view it on GitHub <#7960 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADG5AQ3ORXQA5U5GMBXBKBD2WSCS7AVCNFSM6AAAAABZ5YTJLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJZG44DCMZSGA> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: dragonmacher]*dragonmacher* left a comment (NationalSecurityAgency/ghidra#7960) <#7960 (comment)> I may be confused about what I'm seeing here. It appears that the labels are correctly demangled in the Listing view. We keep the new symbol and the original mangled symbol. It looks like the issue is that the primary label at each address is the original mangled symbol and not the demangled version. When the demangled symbols are applied, the newly demangled symbol will be made primary. But, they may not do this if the existing primary symbol has been changed by the user somehow. The decompiler is using the primary label at a given address, which is why it is showing the mangled symbol. In this example, you can see the primary symbol in blue (the mangled symbol) and the demangled symbol above it in gold. image.png (view on web) <https://github.com/user-attachments/assets/52af0f2d-ec1a-49eb-aa02-e28558211734> — Reply to this email directly, view it on GitHub <#7960 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADG5AQ3ORXQA5U5GMBXBKBD2WSCS7AVCNFSM6AAAAABZ5YTJLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJZG44DCMZSGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dragonmacher]

I have not tested this code, but you should be able to copy and edit the DemangleAllScript to change this:

	DemanglerCmd cmd = new DemanglerCmd(addr, name);
	if (!cmd.applyTo(currentProgram, monitor)) {
		println("Unable to demangle: " + s.getName());
	}

to this:

	DemanglerCmd cmd = new DemanglerCmd(addr, name);
	if (!cmd.applyTo(currentProgram, monitor)) {
		println("Unable to demangle: " + s.getName());
		continue;
	}

	DemangledObject dobj = cmd.getDemangledObject();
	String demangledName = dobj.getName();

	Symbol primarySymbol = st.getPrimarySymbol(addr);
	String currentName = primarySymbol.getName();
	if (currentName.equals(demangledName)) {
		continue; // already primary 
	}

	Namespace ns = primarySymbol.getParentNamespace();
	SetLabelPrimaryCmd setPrimaryCmd = new SetLabelPrimaryCmd(addr, demangledName, ns);
	if (!setPrimaryCmd.applyTo(currentProgram)) {
		println("Unable to set demangled label primary: " + demangledName + " at " + addr);
	}

[Joey35233]

Thanks. I had to add VMARGS=-Dghidra.util.Swing.timeout.seconds=3600 but did get it to run. The results are identical.

I checked, and it seems like the problem is actually in applying it:

DemanglerCmd cmd = new DemanglerCmd(addr, name);
if (!cmd.applyTo(currentProgram, monitor)) {
	println("Unable to demangle: " + s.getName());
	if (s.getName().contains("g_defaultRejectionLevel")) {
		println("GOTCHA!");
		break;
	}
	continue;
}

Another potential issue I discovered in the vanilla DemangleAllScript.java file:

if (name.startsWith("s_") || name.startsWith("u_") || name.startsWith("AddrTable")) {
	println("SKIPPING: " + name);
	continue;
}

I believe this may skip legal, unmangled symbols like this:

 0003:00364890       s_lualfloadfile            0000000142a56890     fox_foundation_win64:luaextfio.obj

although in my case the symbols are still somehow intact:

[dragonmacher]

The script is pretty simple. It just loops over all symbols in the binary, ignoring symbols that do not seem like they are mangled.

It should be encountering demangled symbols in addition to those you are printing out. When it hits those demangled symbols, the applyTo() may be failing for some reason. In that case, you can update the script to work around the issue. In the case that you encounter a valid mangled symbol, you can then get the other symbols at that address that are non-primary. There should already be a demangled symbol there, based on what you posted earlier. You can then change the previously demangled symbol to be the primary symbol, despite the fact that the applyTo() failed.

[josephclampett-education]

Whew, I spent a lot of time messing with this. So yes, you're right - I didn't realize that it iterates over the demangled symbols and mangled symbols. Now, I think I've implemented what you've suggested.

DemangledObject dobj = cmd.getDemangledObject();

...

Symbol searchTarget = null;
Symbol[] symbols = st.getSymbols(address);
for (Symbol symbol : symbols)
{
	if (symbol.getName().equals(dobj.getName())) {
		searchTarget = symbol;
		ns = symbol.getParentNamespace(); // Very important to grab the new namespace as well!
		break;
	}
}

...

new SetLabelPrimaryCmd(address, demangledName, ns)

Unfortunately, a few more problems. The above only works as a symbol "flipper" - gold to blue - but some of the gold labels start out wrong; lots of symbols belong to `anonymous namespace' but that seems to be a Ghidra construct. Sometimes it uses that, sometimes it imports the same thing as a messier _anon symbol:

In this case, the blue is already "demangled" but somehow doesn't follow the same format of its own, much nicer plate comment. The result is an odd mismatch between types where some are in anonymous and some not for no reason that I can tell:

I tried many functions and they give various results. The anonymous namespace is extremely "rare:"

DemangledObject dobj = cmd.getDemangledObject();
dobj.getNamespaceString() // fox::geo::_anon_D5137EAA::g_jobInfo
dobj.getRawDemangled() // class fox::JobInfo fox::geo::`anonymous namespace'::g_jobInfo
dobj.getSignature() // class fox::JobInfo fox::geo::_anon_D5137EAA::g_jobInfo

Demangled dns = dobj.getNamespace();
dns.getDemangledName() // _anon_D5137EAA
dns.getName() // _anon_D5137EAA
dns.getNamespaceName() // _anon_D5137EAA
dns.getNamespaceString() // fox::geo::_anon_D5137EAA
dns.getOriginalDemangled() // A0xd5137eaa

Where does this much cleaner `anonymous namespace' come from and how can I get it back for functions like the above which are missing it? In what I suspect may be a related issue, these functions seem to be okay but are missing that top comment altogether: