Decompiler: x86-16 external functions are not being handled

Describe the bug In x86-16 files such as the NE (new executable) format for Windows where external symbols to DLLs are loaded, the decompiler for whatever reason is being informed of external references but not querying to get the details needed for naming and type information. Instead the raw decompilation contains names like func_0x009002();

To Reproduce

1. Also useful debugging tip - on Windows an API Monitoring tool like API Monitor v2 64-bit from www.rohitab.com (with Tools -> Options -> Memory -> Maximum size of captured buffers = 4096, and filter for Data Access and Storage -> Local File Systems -> File Management -> Kernel32.dll) monitoring Ghidra’s javaw.exe can yield this interface details (in the child decompile.exe process): WriteFile: getMappedSymbolsXML…<addr space="ram" offset="0x9002"/> ReadFile: <result>.<parent>.<val/></parent>.<mapsym>.<externrefsymbol name="Ordinal_1_exref">.<addr space="ram" offset="0x9002"/></externrefsymbol>.<addr space="ram" offset="0x9002"/><rangelist/></mapsym>.</result>

Then the decompilation completes without anything further.

Expected behavior The decompiler is supposed to send getExternalRefXML to get the function details for the external referenced function. It does this consistently on 32 and 64-bit Windows modules.

Environment (please complete the following information):

• OS: Windows 10
• Java Version: 11.0.3
• Ghidra Version: 9.0.4

[caheckman]

This is part of a series of changes to 16-bit analysis that are making their way through review (some are already in master). The NeLoader hadn’t been visited in a while, so some adjustment was necessary anyway to support “protected mode” addressing via the new ProtectedAddressSpace class. For this particular ticket, the decompiler was receiving pointer information for direct calls when it should have been receiving function information. This fix lets the decompiler receive the information normally for a direct call, without having to requery for the information at a later stage of the decompilation.

We’ll repost here when the change is up on master, and you can take a look.

[caheckman]

Yes, it seems the NE importer is improperly creating external references which were designed for indirect calls. Working on fix so the importer properly creates external functions.