<div dir="ltr">I'm a little concerned we got prefix data wrong. We had the following motivating use cases:<div><br><div>1. Function prologue sigils, where we emit a special nop slide, maybe with data in it. Peter implemented a ubsan feature using this.</div>
<div><br></div><div>2. Function hotpatching, where we emit some data before the function and a special nop before the function. Typically the nop is 'mov edi, edi' on x86 Windows, preceded by five bytes of padding for a long jump. Profilers can uses this to turn on and off instrumentation of a running binary.</div>
<div><br></div><div>3. Tables-before-code, where data is completely prior to the code. GHC needs this.</div></div><div><br></div><div>In all cases, any code inside the prologue had no meaning to LLVM. Inlining a function with a funky prologue is completely valid.</div>
<div><br></div><div>I worry that symbol_offset combined with prefix are too low-level. What if we split this up into something like prefix data "prologue" data? Prefix data would be an arbitrary LLVM constant, and prologue data is a byte sequence of native executable code. Something like:</div>
<div><br></div><div>define void @foo() prefix [i8* x 2] { i8* @a, i8* @b } prologue [i8 x 4] c"\xde\xad\xbe\xef" { ret void }</div><div><br></div><div>I think the two forms are fundamentally equivalent to optimizations like global constant propagation, but it'd be nice to have an intuitive representation. One of the strengths of LLVM's IL is that it's comprehensible to mere mortal compiler engineers, and not just computer programs.</div>
<div><br></div><div>---</div><div><br></div><div>P.S. You could also represent this with aliases with a non-zero offset from the beginning of the function. Rafael is implementing this, but I don't think that's a very good representation. What does it mean to inline through an alias to a function with a non-zero offset? We could say that we just ignore the offset for analysis purposes, but it doesn't feel very clean.<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 27, 2014 at 6:13 AM, Ben Gamari <span dir="ltr"><<a href="mailto:bgamari.foss@gmail.com" target="_blank">bgamari.foss@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Somehow this cover letter was dropped from my symbol offsets patch set:<br>
<br>
1. <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073200.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073200.html</a><br>
2. <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073201.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073201.html</a><br>
<br>
<br>
Original message<br>
-----------------<br>
<br>
About a year ago a proposal suggesting symbol offsets was brought to<br>
this list[1]. This proposal goes hand-in-hand with the prefix data<br>
proposal[2] which has now been implemented and I believe both of these<br>
arose in part due to GHC's requirement to place its info tables before<br>
symbol definitions[3]. Unfortunately, the current implementation of<br>
prefix data isn't terribly useful to GHC without symbol offsets[4,5]<br>
<br>
This weekend I implemented option (2) in the original proposal, then<br>
eventually implemented option (1) on top of this. Here is the<br>
result. Note that this can also be found on Github[6] for those who<br>
prefer this.<br>
<br>
A review would be greatly appreciated. One known deficiency of this set<br>
is the lack of tests. Unfortunately, due to the use of temporary symbols<br>
it's not clear to me how this feature can be reliably tested. Ideas<br>
are welcome.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
[1] <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html</a><br>
[2] <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html</a><br>
[3] <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-February/047514.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-February/047514.html</a><br>
[4] <a href="http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html" target="_blank">http://www.haskell.org/pipermail/ghc-devs/2013-September/002565.html</a><br>
[5] <a href="https://ghc.haskell.org/trac/ghc/ticket/4213#comment:12" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/4213#comment:12</a><br>
[6] <a href="https://github.com/bgamari/llvm/compare/symbol-offset" target="_blank">https://github.com/bgamari/llvm/compare/symbol-offset</a><br>
<br>
<br><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>