<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Jonas Wagner via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>llvm-dev@lists.llvm.org<br><b>Sent: </b>Tuesday, January 19, 2016 11:40:16 AM<br><b>Subject: </b>[llvm-dev] Adding support for self-modifying branches to LLVM?<br><br><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><p style="margin: 1.2em 0px ! important;">Hi,</p>
<p style="margin: 1.2em 0px ! important;">I’m thinking about using LLVM to implement a limited form of self-modifying code. Before diving into that, I’d like to get some feedback from you all.</p>
<p style="margin: 1.2em 0px ! important;"><strong>The goal:</strong> I’d like to add “optional” code to a program that I can enable at runtime and that has zero (i.e., as close to zero as I can get) overhead when not enabled.</p>
<p style="margin: 1.2em 0px ! important;"><strong>Existing solutions:</strong> Currently, I can guard optional code using a branch, something like <code style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace; margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); display: inline; background-color: rgb(248, 248, 248);">br i1 %cond, label %optional, label %skip, !prof !0</code>. Branch weights ensure that the branch is predicted correctly. The overhead of this is not as low as I’d like, though, because the branch is still present in the code and because computing <code style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace; margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); display: inline; background-color: rgb(248, 248, 248);">%cond</code> also has some cost.</p>
<p style="margin: 1.2em 0px ! important;"><strong>The idea:</strong> I’d like to have a branch that is the same as the example above, but that gets translated into a <code style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace; margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); display: inline; background-color: rgb(248, 248, 248);">nop</code> instruction. Preferably some unique <code style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace; margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); display: inline; background-color: rgb(248, 248, 248);">nop</code> that I can easily recognize in the binary, and that has the same size as an unconditional branch instruction. Then, I could use a framework such as DynInst to replace that <code style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace; margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); display: inline; background-color: rgb(248, 248, 248);">nop</code> with an unconditional branch instruction at run-time.</p>
<p style="margin: 1.2em 0px ! important;">My questions to the community would be:</p>
<ul style="margin: 1.2em 0px; padding-left: 2em;">
<li style="margin: 0.5em 0px;">Does the idea make sense, or am I missing a much simpler approach?</li>
<li style="margin: 0.5em 0px;">What would be the easiest way to obtain the desired binary? Adding a new TerminatorInstruction sounds daunting, is there something simpler?</li>
</ul>
<p id="DWT1377" style="margin: 1.2em 0px ! important;">I also wonder whether I could even expects speedups from this? Are <code style="font-size: 0.85em; font-family: Consolas,Inconsolata,Courier,monospace; margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); display: inline; background-color: rgb(248, 248, 248);">nop</code> instructions actually cheaper than branches? Would modifying the binary at run-time play well enough with caches etc.? These are probably not questions for the LLVM mailing list, but if anybody has good answers they are welcome.</p></div></div></div></div></blockquote>If you've not already, you'll want to look at this: http://llvm.org/docs/StackMaps.html (it does not quite do what you want, but it should give you some idea on how you might proceed).<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><p style="margin: 1.2em 0px ! important;"></p>
<p style="margin: 1.2em 0px ! important;">Looking forward to hearing your thoughts,<br>Jonas</p>
<div title="MDH:SGksPGRpdj48YnI+PC9kaXY+PGRpdj5JJ20gdGhpbmtpbmcgYWJvdXQgdXNpbmcgTExWTSB0byBp
bXBsZW1lbnQgYSBsaW1pdGVkIGZvcm0gb2Ygc2VsZi1tb2RpZnlpbmcgY29kZS4gQmVmb3JlIGRp
dmluZyBpbnRvIHRoYXQsIEknZCBsaWtlIHRvIGdldCBzb21lIGZlZWRiYWNrIGZyb20geW91IGFs
bC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PioqVGhlIGdvYWw6KiogSSdkIGxpa2UgdG8gYWRk
ICJvcHRpb25hbCIgY29kZSB0byBhIHByb2dyYW0gdGhhdCBJIGNhbiBlbmFibGUgYXQgcnVudGlt
ZSBhbmQgdGhhdCBoYXMgemVybyAoaS5lLiwgYXMgY2xvc2UgdG8gemVybyBhcyBJIGNhbiBnZXQp
IG92ZXJoZWFkIHdoZW4gbm90IGVuYWJsZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4qKkV4
aXN0aW5nIHNvbHV0aW9uczoqKiBDdXJyZW50bHksIEkgY2FuIGd1YXJkIG9wdGlvbmFsIGNvZGUg
dXNpbmcgYSBicmFuY2gsIHNvbWV0aGluZyBsaWtlIGBiciBpMSAlY29uZCwgbGFiZWwgJW9wdGlv
bmFsLCBsYWJlbCAlc2tpcCwgIXByb2YgITBgLiBCcmFuY2ggd2VpZ2h0cyBlbnN1cmUgdGhhdCB0
aGUgYnJhbmNoIGlzIHByZWRpY3RlZCBjb3JyZWN0bHkuIFRoZSBvdmVyaGVhZCBvZiB0aGlzIGlz
IG5vdCBhcyBsb3cgYXMgSSdkIGxpa2UsIHRob3VnaCwgYmVjYXVzZSB0aGUgYnJhbmNoIGlzIHN0
aWxsIHByZXNlbnQgaW4gdGhlIGNvZGUgYW5kIGJlY2F1c2UgY29tcHV0aW5nIGAlY29uZGAgYWxz
byBoYXMgc29tZSBjb3N0LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+KipUaGUgaWRlYToqKiBJ
J2QgbGlrZSB0byBoYXZlIGEgYnJhbmNoIHRoYXQgaXMgdGhlIHNhbWUgYXMgdGhlIGV4YW1wbGUg
YWJvdmUsIGJ1dCB0aGF0IGdldHMgdHJhbnNsYXRlZCBpbnRvIGEgYG5vcGAgaW5zdHJ1Y3Rpb24u
IFByZWZlcmFibHkgc29tZSB1bmlxdWUgYG5vcGAgdGhhdCBJIGNhbiBlYXNpbHkgcmVjb2duaXpl
IGluIHRoZSBiaW5hcnksIGFuZCB0aGF0IGhhcyB0aGUgc2FtZSBzaXplIGFzIGFuIHVuY29uZGl0
aW9uYWwgYnJhbmNoIGluc3RydWN0aW9uLiBUaGVuLCBJIGNvdWxkIHVzZSBhIGZyYW1ld29yayBz
dWNoIGFzIER5bkluc3QgdG8gcmVwbGFjZSB0aGF0IGBub3BgIHdpdGggYW4gdW5jb25kaXRpb25h
bCBicmFuY2ggaW5zdHJ1Y3Rpb24gYXQgcnVuLXRpbWUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp
dj5NeSBxdWVzdGlvbnMgdG8gdGhlIGNvbW11bml0eSB3b3VsZCBiZTo8L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2Pi0gRG9lcyB0aGUgaWRlYSBtYWtlIHNlbnNlLCBvciBhbSBJIG1pc3NpbmcgYSBt
dWNoIHNpbXBsZXIgYXBwcm9hY2g/PC9kaXY+PGRpdj4tIFdoYXQgd291bGQgYmUgdGhlIGVhc2ll
c3Qgd2F5IHRvIG9idGFpbiB0aGUgZGVzaXJlZCBiaW5hcnk/IEFkZGluZyBhIG5ldyBUZXJtaW5h
dG9ySW5zdHJ1Y3Rpb24gc291bmRzIGRhdW50aW5nLCBpcyB0aGVyZSBzb21ldGhpbmcgc2ltcGxl
cj88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgYWxzbyB3b25kZXIgd2hldGhlciBJIGNvdWxk
IGV2ZW4gZXhwZWN0cyBzcGVlZHVwcyBmcm9tIHRoaXM/IEFyZSBgbm9wYCBpbnN0cnVjdGlvbnMg
YWN0dWFsbHkgY2hlYXBlciB0aGFuIGJyYW5jaGVzPyBXb3VsZCBtb2RpZnlpbmcgdGhlIGJpbmFy
eSBhdCBydW4tdGltZSBwbGF5IHdlbGwgZW5vdWdoIHdpdGggY2FjaGVzIGV0Yy4/IFRoZXNlIGFy
ZSBwcm9iYWJseSBub3QgcXVlc3Rpb25zIGZvciB0aGUgTExWTSBtYWlsaW5nIGxpc3QsIGJ1dCBp
ZiBhbnlib2R5IGhhcyBnb29kIGFuc3dlcnMgdGhleSBhcmUgd2VsY29tZS48YnI+PC9kaXY+PGRp
dj48YnI+PC9kaXY+PGRpdj5Mb29raW5nIGZvcndhcmQgdG8gaGVhcmluZyB5b3VyIHRob3VnaHRz
LDwvZGl2PjxkaXY+Sm9uYXM8L2Rpdj4=" style="min-height: 0pt; width: 0pt; max-height: 0pt; max-width: 0pt; overflow: hidden; font-size: 0em; padding: 0pt; margin: 0pt;"></div></div></div></div></div>
<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>