On Wed, Nov 12, 2025 at 04:12:08AM +0000, Michael Kelley wrote: > > @@ -96,3 +97,10 @@ SYM_FUNC_START(__mshv_vtl_return_call) > > pop %rbp > > RET > > SYM_FUNC_END(__mshv_vtl_return_call) > > + > > + .section .discard.addressable,"aw" > > + .align 8 > > + .type > > __UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0, @object > > + .size > > __UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0, 8 > > +__UNIQUE_ID_addressable___SCK____mshv_vtl_return_hypercall_662.0: > > + .quad __SCK____mshv_vtl_return_hypercall > > This is pretty yucky itself.
Definitely doesn't win any prizes, for sure. > Why is it better than calling out to a C function? It keeps all the code in one place is a strong argument. > Is it because in spite of the annotations, there's no guarantee the C > compiler won't generate some code that messes up a register value? Or is > there some other reason? There is that too, a frame pointer build would be in its right to add a stack frame (although they typically won't in this case). And the C ABI doesn't provide the guarantees your need, so calling out into C is very much you get to keep the pieces. > Does the magic "_662.0" have any significance? Or is it just some > uniqueness salt on the symbol name? Like Paolo already said, that's just the crazy generated by our __ADRESSABLE() macro, this name is mostly irrelevant, all we really need is a reference to that __SCK____mshv_vtl_return_hypercall symbol so it ends up in the symbol table. (And the final link will then complain if the symbol doesn't end up being resolved) Keeping the name somewhat in line with __ADDRESSABLE() has the advantage that you can clearly see where it comes from, but yeah, we can strip of the number if you like.
