Functions are being created for jump tables in code sections

[WeiN76LQh]

Version and Platform (required):

• Binary Ninja Version: 5.3.9208-dev Ultimate (8b909a0c)
• Edition: Ultimate
• OS: macOS
• OS Version: 26.3
• CPU Architecture: M1

Bug Description:
It seems Binary Ninja is overwriting jump tables in code sections with functions even though it has correctly identified them as jump tables. The symbol of the function is a data symbol as well.

Steps To Reproduce:

1. Open a recent copy of the DYLD Shared Cache with default load settings so libsystem_c.dylib is loaded automatically.
2. Wait for initial analysis to complete.
3. Go to any of the unnamed functions (beginning with sub_).
4. Observe that they all seem to be for jump tables are not actual functions.

Expected Behavior:
Jump tables in code sections shouldn't be overwritten with functions.

Screenshots/Video Recording:

Navigating to the symbol for one of the unnamed functions thats actually a jump table:

Navigate to the reference to the jump table:

It appears the jump table is working correctly as a switch case.

Binary:
DYLD Shared Cache for an iPhone 17 Pro Max running iOS 26.0

Additional Information:
I confirmed the behaviour is exactly the same when running Binary Ninja with plugins disabled.

[plafosse]

This is actually kind of the opposite of what you're saying. The function is first identified and then the jump table goes and overwrites the function. It's happening because that address is listed in the functionStarts table.

	if (header.linkeditPresent && m_vm->IsAddressMapped(header.linkeditSegment.vmaddr))
	{
		if (m_applyFunctions && header.functionStartsPresent)
		{
			auto targetPlatform = m_view->GetDefaultPlatform();
			auto functions = header.ReadFunctionTable(*m_vm);
			for (const auto& func : functions)
				m_view->AddFunctionForAnalysis(targetPlatform, func, false); // <=== this code is adding that address.
		}

I'm not sure what can be done about this other than perhaps resorting to heuristic code/data disambiguation.

[WeiN76LQh]

Huh, thats kind of odd/unfortunate, makes fixing it not hugely worth the effort. I think you're right that some kind of heuristic would be required but that could open up the potential for other bugs. The only alternative I can think of is if there are some kind of flags/metadata in Mach-Os/DSC that indicate a function start is for a jump table.

[plafosse]

PR #8002 "fixes" the issue by adding a dumb heuristic that should pretty much have no false positives but could have tons of false negatives (no worse than where we're at right now). I does work on all the messed up jump tables in the DSC though.