> What other strategies can we pursue?

You can use thunks/trampolines. lld can make them for some architectures, presumably also for x86_64. Though I don't know why it didn't in your case.

But, like the large code model it can be expensive to add trampolines, both in icache performance and just execution if a trampoline is in a particularly hot path.

▲

setheron 8 hours ago | parent | next [-]

In many ways that is what the PLT is also.

This is what my next post will explore. I ran into some issues with the GOT that I'll have to explore solutions for.

I'm writing this for myself mostly. The whole idea for code models when you have thunks feels unnecessary.

▲

setheron 5 hours ago | parent | prev [-]

follow-up: https://fzakaria.com/2025/12/29/huge-binaries-i-thunk-theref...

	▲	wyldfire 4 hours ago \| parent [-]
		> With this information, the necessity of code-models feels unecessary [sic]. Why trigger the cost for every callsite when we can do-so piecemeal as necessary with the opportunity to use profiles to guide us on which methods to migrate to thunks. Does the linker have access to the same hotness information that the compiler uses during PGO? Well -- presumably it could, even if it doesn't now. But it would be like a heuristic with a hotness threshold? Do linkers "do" heuristics?