<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 14, 2018 at 2:34 AM, David Woodhouse <span dir="ltr"><<a href="mailto:dwmw2@infradead.org" target="_blank">dwmw2@infradead.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">Let's not conflate the asm-goto part with the .pushsection/.popsection.</span><br></div></div>
<br>
The latter ("0: .pushsection foo; .long 0b; .popsection") is used *all*<br>
over the kernel to build up tables of code locations — for exception<br>
handling of instructions which might fault, as well as for runtime<br>
patching of instructions like the above. It's not always a nop vs. call<br>
alternative.<br>
<br>
It would be nice to have the compiler assist with that. We currently<br>
have code to trawl through all the built object files and find calls to<br>
__fentry__ so we can patch them in/out at runtime, for example. And we<br>
might considered doing the same for calls to the retpoline thunks.<br>
<br>
But I think we would be best served right now by considering that out<br>
of scope, and looking *only* at the part which is handled by 'asm<br>
goto'.<br></blockquote><div><br></div><div>Collecting labels in code is a pretty interesting and reasonable use case. I'd be really interested in a separate discussion or document describing the kernel use cases for this. In particular, I'm worried about what things LLVM might hoist across the label. We might want to end up designing something more like real asynchronous exception handling (__try) than all this assembly blob stuff.</div><div><br></div><div>But I agree, asm-goto is probably higher priority.</div></div></div></div>