macOS kernel "Add to Program" doesn't fix decompiler output

[nmggithub]

Describe the bug
See steps.

To Reproduce
Steps to reproduce the behavior:

1. Load a macOS kext using a kernelcache as a filesystem.
2. Use the "Add to program" flow to add another file from that filesystem to the Program.
3. Observe the function names appearing in the disassembly, but not the decompilation.

Expected behavior
The function names should appear in both the disassembly and the decompilation.

Screenshots

Environment (please complete the following information):
Note: This is mostly copied from one of my most recent issues. To the best of my knowledge, it is still accurate.

• OS: macOS 26.0 beta 8 (25A5349a)
• Java Version: openjdk version "23.0.2" 2025-01-21
• Ghidra Version: Commit 7482131bcc0800401cd5564393d771eea7f72d6f with 0464fc981f5d8c1bf481b72b4b5ba6f12d8bd2ef cherry-picked on top
• Ghidra Origin: locally built

Additional context
It's possible I'm used to the user space pattern where functions are calls to thunks instead of directly to other functions like is the case here with the macOS kernel. In user space, the thunk functions are fully decompiled (as they are only a few instructions long). That might be what makes them appear in the decompilation, but I could be wrong. I'd rather not have to decompile a function in order to show named references to it in the decompilation output.

[astrelsky]

When was that call signature override created? Was it before or after adding the kernel module?

If the override was added before, try deleting the override label and see what happens.

[nmggithub]

When was that call signature override created? Was it before or after adding the kernel module?

If the override was added before, try deleting the override label and see what happens.

It was added after using "Add to Program". Non-overridden functions also exhibit this behavior.

[astrelsky]

When was that call signature override created? Was it before or after adding the kernel module?

If the override was added before, try deleting the override label and see what happens.

It was added after using "Add to Program". Non-overridden functions also exhibit this behavior.

The kernel module wasn't loaded into an overlay was it? I know the decompiler will only show the function call correctly if they are in the same address space (Ghidra address space)

[nmggithub]

When was that call signature override created? Was it before or after adding the kernel module?
If the override was added before, try deleting the override label and see what happens.

It was added after using "Add to Program". Non-overridden functions also exhibit this behavior.

The kernel module wasn't loaded into an overlay was it? I know the decompiler will only show the function call correctly if they are in the same address space (Ghidra address space)

I'm not sure. All I did was follow the "Add to Program" pattern in the GUI.

[ryanmkurtz]

Did you analyze, add to program, and then analyze again? do you get the problem if you add everything first and then analyze?

[nmggithub]

Did you analyze, add to program, and then analyze again? do you get the problem if you add everything first and then analyze?

I would assume one of these options could work, but I assume analysis would cause Ghidra to decompile the added kext functions and, honestly, I would like to avoid that as the function names are really all I care about. Do I need to run analysis afterwards? I never really had to do that when dealing with user space binaries.

[ryanmkurtz]

When you do an Add To Program, analysis does not automatically happen. You have to kick it off if you want the new stuff analyzed. I'm not sure that's the issue here...I was just trying to gather info about your workflow before i try to reproduce.

[nmggithub]

I figured something out. If I manually right click each callsite and select "Modify Instruction Flow...", select "CALL" from the dropdown, and click "OK", the actual function name appears in the decompilation.

EDIT: It doesn't seem to actually change the underlying flow type at times? But it might trigger the displaying of the function names as a side effect.

EDIT 2: I discovered this after playing around with "Modify Instruction Flow..." as incorrect flow types seems to be causing other weirdness in the decompiler where it eventually devolves into gibberish. I have been able to fix the issues I have found so far, though.

EDIT 3: After modifying the instruction flow, it seems all callsites of that particular function now show the function name, even in other functions in the Program. That's nice, but it does seem to indicate the behavior is incidental and not directly a result of setting the instruction flow.

[astrelsky]

This is giving me déjà vu. Unfortunately I don't have anything to offer other than that. I just feel like I remember seeing this, somewhere.