<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> why isn&#39;t the hague doing anything about this?</p>

<p><span class="h-card" translate="no"><a href="https://60228.dev/@leo" class="u-url mention">@<span>leo</span></a></span> yeah ok but at least they didn&#39;t require a like, different compiler</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>whitequark</span></a></span> i SWEAR some "7th generation" parts with later manufacturing dates were secretly coffee lake, or something along those lines</p>

<p><span class="h-card" translate="no"><a href="https://wolfdo.gg/@unnick" class="u-url mention">@<span>unnick</span></a></span> it has, afaict, different connectivity and timings. depending on the datecode.</p>

<p><span class="h-card" translate="no"><a href="https://60228.dev/@leo" class="u-url mention">@<span>leo</span></a></span> they what</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>whitequark</span></a></span> didn't intel do this too on laptop cpus a few generations ago</p>

<p>in order to know which architecture the part has you have to consult the datecode</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> LLVM libunwind implements them as normal extern functions <a href="https://github.com/llvm/llvm-project/blob/main/libunwind/include/libunwind.h#L109-L116" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">github.com/llvm/llvm-project/b</span><span class="invisible">lob/main/libunwind/include/libunwind.h#L109-L116</span></a></p><p>to implement them it defines e.g. __unw_step (that it uses internally in its own implementation), hides that, and then adds a weak alias from unw_step to __unw_step so that it doesn&#39;t conflict with other stuff that may be on your system</p>

<p>So, with that out of the way, the answers to my top of thread questions:</p><p>- Savannah/HP libunwind and Clang/LLVM libunwind are C/C++ source compatible. The developer-facing function interfaces are the same.</p><p>- However, the *set of exported symbols in the libraries* are totally different. C/C++ source compatibility is only possible because both(?) libraries implement the functions as macros.</p><p>- Therefore, if you access these libraries from a non C language like Rust, they&#39;re fully incompatible.</p>