Incorrect stack variables detection and usage on x86

[americusmaximus]

Describe the bug

The following program breaks Ghidra's detection and use of local (stack) variables, if compiled with Visual C++ 6:

Once compiled with Visual C++ 6, analyzed and decompiled by Ghidra, the stack variables are missing:

Even though the disassembly listing shows the population of the local variables:

The same code compiled with Visual Studio 2005 is being recognized correctly:

To Reproduce

1. Compile Main.cpp from the attached archive Example.zip with Visual C++ 6 and analyze it with Ghidra. Or analyze VC6.exe from the same archive right away.
2. Verify that local variables are not detected and a bunch of assembly instructions are skipped by Ghidra during decompilation.

Expected behavior
The local variables have to be detected and populated in VC6.exe in the same manner as in 2005.exe (compiled with Visual Studio 2005)

Attachments
Example.zip

Environment (please complete the following information):

• OS: Microsoft Windows [Version 10.0.19045.5247]
• Java Version: 23.0.1
• Ghidra Version: 11.2 Public
• Ghidra Origin: Official GitHub distribution

[ABratovic]

Hi there, I think troubleshooting your issue could be better approached by looking at how did Ghidra know to assign the stack variables in your 2005.exe. The first observation is that the 2005 decompilation has identified the imports from a separate kernel32.dll AND MSVCR80.dll which gives ghidra the function prototype for printf and allows it to identify and propagate the local stack variables.

The size of VC6.exe indicates that it has been compiled to use kernel32.dll but has static copy of the runtime library including _printf function at FUN_401060. It's possible that if you were to compile VC6.exe to use msvcr?.dll there is already an export file available that will provide the _printf prototype and thus propagate the local variables.

But with your current VC6.exe the issue (to me) is how best to create gdt and fidb files specific to VC6 (currently there is only vsOlder_x86.fidb that includes the VS2005 libraries) to identify FUN_401060 as a _printf library function.

[americusmaximus]

@ABratovic,

You are correct, the VC6 example has C runtime linked as static library, while VS 2005 example is linked dynamically. Those are just default settings. If you change VS 2005 build configuration to link with CRT statically, Ghidra still has relatively good capability of identifying CRT function, which is not the case for VC6 at all.

You are correct once more, the issue is with the dataset for matching functions. I'd be happy to contribute to such a dataset, if there is a way to do so. Is there a way?

P.S. The original issue is about the stack variables initialization and use, which is higher of a priority on my list than VC++ 6.0 functions.