<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>

<p>Okay. I&#39;ve talked to some people and some things have been explained to me. I now understand the origin of the linker error.</p><p>First, let me clarify something: it was incorrect or imprecise to refer to &quot;gcc libunwind&quot; in the top post. I think it is probably clearest to refer to this library (Debian &quot;libunwind-dev&quot;, with no numbers) as &quot;Savannah libunwind&quot;. According to <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span>, this *is* &quot;HP Libunwind&quot; (through some former open source release, I guess?)</p>

<p>OH: &quot;AU where Robert Tomasulo is a puppygirl&quot;</p>

<p><span class="h-card"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> </p><p><a href="https://mastodon.sdf.org/tags/Intel" class="mention hashtag" rel="tag">#<span>Intel</span></a> : goes through hell to design an entirely new instruction set architecture and calls it <a href="https://mastodon.sdf.org/tags/Itanium" class="mention hashtag" rel="tag">#<span>Itanium</span></a></p><p>Everyone: “We&#39;ll just take the <a href="https://mastodon.sdf.org/tags/C" class="mention hashtag" rel="tag">#<span>C</span></a>++ <a href="https://mastodon.sdf.org/tags/ABI" class="mention hashtag" rel="tag">#<span>ABI</span></a>, thanks. We&#39;re going with <a href="https://mastodon.sdf.org/tags/AMD" class="mention hashtag" rel="tag">#<span>AMD</span></a> for everything else. Toodles.”</p>

<p><a href="https://github.com/amaranth-lang/amaranth/pull/734#discussion_r1290086512" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">github.com/amaranth-lang/amara</span><span class="invisible">nth/pull/734#discussion_r1290086512</span></a></p>