<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Another option is mcsema, which supports lifting x86 binaries to LLVM IR:<div><br></div><div><a href="https://github.com/trailofbits/mcsema">https://github.com/trailofbits/mcsema</a></div><div><br></div><div>Artem</div><div><br></div><div><br><div><div><div>On Mar 13, 2015, at 12:16 PM, <a href="mailto:llvmdev-request@cs.uiuc.edu">llvmdev-request@cs.uiuc.edu</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Send LLVMdev mailing list submissions to<br><span class="Apple-tab-span" style="white-space:pre"> </span><a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><span class="Apple-tab-span" style="white-space:pre"> </span>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br>or, via email, send a message with subject or body 'help' to<br><span class="Apple-tab-span" style="white-space:pre"> </span>llvmdev-request@cs.uiuc.edu<br><br>You can reach the person managing the list at<br><span class="Apple-tab-span" style="white-space:pre"> </span>llvmdev-owner@cs.uiuc.edu<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of LLVMdev digest..."<br><br><br>Today's Topics:<br><br> 1. Re: [cfe-dev] Commit message policy? (Hal Finkel)<br> 2. Re: Reminder 3.5.2 merge deadline is Monday, Mar 16 - Testers<br> needed (Hans Wennborg)<br> 3. Contracting Opportunity for LLVM (Aptezzo Information)<br> 4. Re: PRE implementation in LLVM (Aradhya Biswas)<br> 5. Lifting ASM to IR (Daniel Dilts)<br> 6. Re: Lifting ASM to IR (Joerg Sonnenberger)<br> 7. Re: Lifting ASM to IR (Ahmed Bougacha)<br> 8. Re: Reminder 3.5.2 merge deadline is Monday,<span class="Apple-tab-span" style="white-space:pre"> </span>Mar 16 - Testers<br> needed (Ben Pope)<br> 9. Re: Contracting Opportunity for LLVM (Tim Northover)<br> 10. Re: Lifting ASM to IR (Daniel Dilts)<br> 11. Re: Contracting Opportunity for LLVM (Aptezzo Information)<br> 12. Re: Indexed Load and Store Intrinsics - proposal (Hao Liu)<br> 13. Re: Passing a function pointer as parameter to function call?<br> (John Criswell)<br> 14. Re: CFG Customization (Thomas Rubiano)<br> 15. Re: [cfe-dev] Commit message policy? (Renato Golin)<br> 16. Re: Reminder 3.5.2 merge deadline is Monday, Mar 16 - Testers<br> needed (Sebastian Dre?ler)<br> 17. Re: Reminder 3.5.2 merge deadline is Monday, Mar 16 - Testers<br> needed (Renato Golin)<br> 18. Re: Lifting ASM to IR (Jonathan Roelofs)<br> 19. Re: On LLD performance (Shankar Easwaran)<br> 20. Re: On LLD performance (Rafael Esp?ndola)<br> 21. Re: Lifting ASM to IR (Daniel Dilts)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 12 Mar 2015 17:39:27 -0500<br>From: Hal Finkel <hfinkel@anl.gov><br>To: Renato Golin <renato.golin@linaro.org><br>Cc: Clang Dev <cfe-dev@cs.uiuc.edu>, LLVM Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] [cfe-dev] Commit message policy?<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><15717370.664.1426199965656.JavaMail.javamailuser@localhost><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Renato,<br><br>Can you please update the patch on http://reviews.llvm.org/D8197 so that we can see what it is you plan to commit?<br><br>Thanks again,<br>Hal<br><br>----- Original Message -----<br><blockquote type="cite">From: "Renato Golin" <renato.golin@linaro.org><br>To: "Michael M Kuperstein" <michael.m.kuperstein@intel.com><br>Cc: "LLVM Dev" <llvmdev@cs.uiuc.edu>, "Clang Dev" <cfe-dev@cs.uiuc.edu>, "Hal Finkel" <hfinkel@anl.gov><br>Sent: Thursday, March 12, 2015 5:22:23 PM<br>Subject: Re: [LLVMdev] [cfe-dev] Commit message policy?<br><br>Gentle ping?<br><br>On 11 March 2015 at 16:12, Renato Golin <renato.golin@linaro.org><br>wrote:<br><blockquote type="cite">If everyone's happy, I'll commit the change and see where we go<br>from then, ok?<br><br>cheers,<br>--renato<br></blockquote><br></blockquote><br>-- <br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<br><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 12 Mar 2015 16:04:48 -0700<br>From: Hans Wennborg <hans@chromium.org><br>To: Tom Stellard <tom@stellard.net><br>Cc: llvmdev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Reminder 3.5.2 merge deadline is Monday, Mar 16<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Testers needed<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAB8jPheHu9ULuyZccSX1sgCB4JVd4pDazHC-CovDrLb+ivDUeg@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>On Thu, Mar 12, 2015 at 3:04 PM, Tom Stellard <tom@stellard.net> wrote:<br><blockquote type="cite">Hi,<br><br>Just a reminder that testing for 3.5.2 will begin on Monday, Mar 16. If<br>you have any patches you want merged please send an email to the<br>relevant commits list and cc me and the code owner. If you have already<br>done this and are waiting for a response, please ping the thread.<br><br>As always we need testers, so let me know if you want to help with<br>testing.<br></blockquote><br>I'm happy to build and test on Windows as usual.<br><br>Thanks,<br>Hans<br><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 12 Mar 2015 17:10:50 -0700<br>From: Aptezzo Information <info@aptezzo.com><br>To: llvmdev@cs.uiuc.edu<br>Subject: [LLVMdev] Contracting Opportunity for LLVM<br>Message-ID: <67176461-5474-470B-8634-42E6D2765C2A@aptezzo.com><br>Content-Type: text/plain; charset=us-ascii<br><br>One of my clients is developing a radical new computer architecture with a proprietary instruction set and a large number of cores. They have a basic LLVM based compiler chain working, but it needs a lot more and they are considering outsourcing some of the development. Ideally this would be an intact working team with LLVM core competency along with history of optimization on a unique architecture. That's a lot to ask so I thought I'd query this list for ideas. It can't be a foreign entity unfortunately. Please contact me with any ideas.<br><br>Thanks for your assistance<br><br>-Jeff<br>info@aptezzo.com<br>760.712.3377<br><br><br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Fri, 13 Mar 2015 06:00:07 +0530<br>From: Aradhya Biswas <cs11b003@iith.ac.in><br>To: llvmdev@cs.uiuc.edu<br>Subject: Re: [LLVMdev] PRE implementation in LLVM<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CANg=q5sp1DkT1hAQ8ttqnZv0C8dYFXaOiumW_Yp0NRy4OnhxNg@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi all,<br><br>This email is to serve as a reminder in regards to my previous email<br>querying about the present implementation of PRE in LLVM.<br><br>In case the present scope of PRE in LLVM is as I mentioned my previous<br>email, which is fairly restricted, than I would like to take it up as a<br>GSoC project to extend the scope of PRE in LLVM.<br><br>Thanks,<br>Aradhya Biswas,<br>Final Year Undergraduate Student,<br>Department of Computer Science and Engineering,<br>Indian Institute of Technology Hyderabad<br><br>On Tue, Mar 10, 2015 at 6:06 PM, Aradhya Biswas <cs11b003@iith.ac.in> wrote:<br><br><blockquote type="cite">Hello everyone,<br><br>I am Aradhya Biswas, currently in senior year of my undergraduate studies<br>in the field of Computer Science and Engineering at Indian Institute of<br>Technology Hyderabad (IITH).<br><br>I was first introduced to LLVM about a year ago in the course "Principles<br>of Compiler Design" (http://www.iith.ac.in/~ramakrishna/Compilers-Aug14/)<br>at IITH. Since the introduction, I have used LLVM for a multitude of my<br>course assignments and mini-projects.<br><br>While studying the compiler optimization theory, LLVM always served as<br>best tool for experimenting. But recently when I came across the concept of<br>Partial Redundancy Elimination, I could not find any exclusive<br>implementation of it in the present LLVM framework. On digging a little<br>deeper, I could find that the implementation of GVN subsumes the load PRE<br>and a specific case (namely, the diamond case) of scalar PRE in the present<br>LLVM framework.<br><br>I had two question in this regards :<br><br> 1. Where can I find the theory related to load PRE implemented here<br> <http://llvm.org/docs/doxygen/html/GVN_8cpp_source.html> (line no.<br> 01517) ?<br> 2. Are there any other implementation of PRE in the present LLVM<br> framework ?<br><br>Thanks,<br>Aradhya Biswas<br>Final Year Undergraduate Student,<br>Department of Computer Science and Engineering,<br>Indian Institute of Technology Hyderabad<br><br></blockquote>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150313/0064b7e8/attachment-0001.html><br><br>------------------------------<br><br>Message: 5<br>Date: Thu, 12 Mar 2015 17:44:02 -0700<br>From: Daniel Dilts <diltsman@gmail.com><br>To: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu><br>Subject: [LLVMdev] Lifting ASM to IR<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CANgHf=yp3TcERC9saQS+HNZZypGWBy9ZwG3AMxA4zG5rnW5esw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Does there exist a tool that could lift a binary (assembly for some<br>supported target) to LLVM IR? If there isn't, does this seem like<br>something that would be feasible?<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150312/36eae2e4/attachment-0001.html><br><br>------------------------------<br><br>Message: 6<br>Date: Fri, 13 Mar 2015 02:05:07 +0100<br>From: Joerg Sonnenberger <joerg@britannica.bec.de><br>To: llvmdev@cs.uiuc.edu<br>Subject: Re: [LLVMdev] Lifting ASM to IR<br>Message-ID: <20150313010507.GA8297@britannica.bec.de><br>Content-Type: text/plain; charset=us-ascii<br><br>On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:<br><blockquote type="cite">Does there exist a tool that could lift a binary (assembly for some<br>supported target) to LLVM IR? If there isn't, does this seem like<br>something that would be feasible?<br></blockquote><br>http://llvm.org/devmtg/2013-04/bougacha-slides.pdf<br>might be a starting point.<br><br>Joerg<br><br><br>------------------------------<br><br>Message: 7<br>Date: Thu, 12 Mar 2015 18:33:23 -0700<br>From: Ahmed Bougacha <ahmed.bougacha@gmail.com><br>To: Daniel Dilts <diltsman@gmail.com><br>Cc: LLVM Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Lifting ASM to IR<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAOprbYQ-wdiKZr6mcj+vseG+RFP4dYaT0se40Yq2h5XawUxkKw@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br><blockquote type="cite">On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:<br><blockquote type="cite">Does there exist a tool that could lift a binary (assembly for some<br>supported target) to LLVM IR? If there isn't, does this seem like<br>something that would be feasible?<br></blockquote></blockquote><br>There's plenty of variations on the idea: Revgen/S2E, Fracture, Dagger<br>(my own), libcpu, several closed-source ones used by pentest shops,<br>some that use another representation before going to IR (say<br>llvm-qemu), and probably others still I forgot about.<br><br>Are you interested in a specific target / use case?<br><br><blockquote type="cite">http://llvm.org/devmtg/2013-04/bougacha-slides.pdf<br>might be a starting point.<br></blockquote><br>Note that after a hiatus I've been slowly revamping Dagger (more to<br>come), making the implementation parts of the slides tremendously<br>out-of-date (it doesn't help that, at the time, I was a kid with a<br>laptop and a dream - not to say I'm much more now).<br><br>For instance, the translation now re-uses the existing<br>instruction-selection patterns in LLVM as much as possible, rather<br>than hand-writing them.<br><br>Also note that, as opposed to the other projects, it's a for-fun<br>hobby, so you might want to investigate your options ;)<br><br>-Ahmed<br><br><br>------------------------------<br><br>Message: 8<br>Date: Fri, 13 Mar 2015 09:41:47 +0800<br>From: Ben Pope <benpope81@gmail.com><br>To: llvmdev@cs.uiuc.edu<br>Subject: Re: [LLVMdev] Reminder 3.5.2 merge deadline is Monday,<span class="Apple-tab-span" style="white-space:pre"> </span>Mar 16<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Testers needed<br>Message-ID: <mdtf8s$brh$1@ger.gmane.org><br>Content-Type: text/plain; charset=windows-1252; format=flowed<br><br>On Friday, March 13, 2015 06:04 AM, Tom Stellard wrote:<br><blockquote type="cite">Hi,<br><br>Just a reminder that testing for 3.5.2 will begin on Monday, Mar 16. If<br>you have any patches you want merged please send an email to the<br>relevant commits list and cc me and the code owner. If you have already<br>done this and are waiting for a response, please ping the thread.<br><br>As always we need testers, so let me know if you want to help with<br>testing.<br></blockquote><br>Happy to test Ubuntu 14.04 x86_64 as usual.<br><br>Ben<br><br><br><br><br>------------------------------<br><br>Message: 9<br>Date: Thu, 12 Mar 2015 19:09:40 -0700<br>From: Tim Northover <t.p.northover@gmail.com><br>To: Aptezzo Information <info@aptezzo.com><br>Cc: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Contracting Opportunity for LLVM<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAFHTzf+2VQxOfAM4wWGcK2NoW8bBK=eyBEz-VxcXHe_F_U0oeA@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br><blockquote type="cite">It can't be a foreign entity unfortunately.<br></blockquote><br>Foreign to whom?<br><br>Tim.<br><br><br>------------------------------<br><br>Message: 10<br>Date: Thu, 12 Mar 2015 19:14:34 -0700<br>From: Daniel Dilts <diltsman@gmail.com><br>To: Ahmed Bougacha <ahmed.bougacha@gmail.com><br>Cc: LLVM Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Lifting ASM to IR<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CANgHf=wGaYSfnnJS+3WjtuhwJAMZhP9DjXMxw7xHxcrq-BotiA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Thu, Mar 12, 2015 at 6:33 PM, Ahmed Bougacha <ahmed.bougacha@gmail.com><br>wrote:<br><br><blockquote type="cite"><blockquote type="cite">On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:<br><blockquote type="cite">Does there exist a tool that could lift a binary (assembly for some<br>supported target) to LLVM IR? If there isn't, does this seem like<br>something that would be feasible?<br></blockquote></blockquote><br>There's plenty of variations on the idea: Revgen/S2E, Fracture, Dagger<br>(my own), libcpu, several closed-source ones used by pentest shops,<br>some that use another representation before going to IR (say<br>llvm-qemu), and probably others still I forgot about.<br><br>Are you interested in a specific target / use case?<br><br></blockquote><br>I was thinking something along the lines of lifting a binary into IR and<br>spitting it out for a different processor.<br><br>Or maybe a decompiling tool of some kind.<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150312/49130ac4/attachment-0001.html><br><br>------------------------------<br><br>Message: 11<br>Date: Thu, 12 Mar 2015 19:17:23 -0700<br>From: Aptezzo Information <info@aptezzo.com><br>To: Tim Northover <t.p.northover@gmail.com><br>Cc: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Contracting Opportunity for LLVM<br>Message-ID: <FC1D180B-FE62-46C9-85BD-9E1DEDDE35DB@aptezzo.com><br>Content-Type: text/plain; charset=us-ascii<br><br>Doh! sorry. Very US centric. Foreign to US.<br><br>On Mar 12, 2015, at 7:09 PM, Tim Northover <t.p.northover@gmail.com> wrote:<br><br><blockquote type="cite"><blockquote type="cite">It can't be a foreign entity unfortunately.<br></blockquote><br>Foreign to whom?<br><br>Tim.<br></blockquote><br><br><br>------------------------------<br><br>Message: 12<br>Date: Fri, 13 Mar 2015 11:55:30 +0800<br>From: Hao Liu <haoliuts@gmail.com><br>To: "Demikhovsky, Elena" <elena.demikhovsky@intel.com><br>Cc: "llvmdev@cs.uiuc.edu" <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Indexed Load and Store Intrinsics - proposal<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CA+0MTkh3=BbtZqBXF6WNn1Dj3M5n2MiCz68TTRVYC5hVqAL4dg@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Hi Elena,<br><br>I think such intrinsics are very useful.<br>Do you have any plan to upstream them?<br><br>Thanks,<br>-Hao<br><br>2014-12-18 22:40 GMT+08:00 Demikhovsky, Elena <elena.demikhovsky@intel.com>:<br><blockquote type="cite">Hi,<br><br>Recent Intel architectures AVX-512 and AVX2 provide vector gather and/or<br>scatter instructions.<br>Gather/scatter instructions allow read/write access to multiple memory<br>addresses. The addresses are specified using a base address and a vector of<br>indices.<br>We?d like Vectorizers to tap this functionality, and propose to do so by<br>introducing new intrinsics:<br><br>VectorValue = @llvm.sindex.load (BaseAddr, VectorOfIndices, Scale)<br>VectorValue = @llvm.uindex.load (BaseAddr, VectorOfIndices, Scale)<br>VectorValue = @llvm.sindex.masked.load (BaseAddr, VectorOfIndices, Scale,<br>PassThruVal, Mask)<br>VectorValue = @llvm.uindex.masked.load (BaseAddr, VectorOfIndices, Scale,<br>PassThruVal, Mask)<br><br>Semantics:<br>For i=0,1,?,N-1: if (Mask[i]) {VectorValue[i] = *(BaseAddr +<br>VectorOfIndices[i]*Scale) else VectorValue[i]=PassThruVal[i];}<br><br>void @llvm.sindex.store (BaseAddr, VectorValue, VectorOfIndices, Scale)<br>void @llvm.uindex.store (BaseAddr, VectorValue, VectorOfIndices, Scale)<br>void @llvm.sindex.masked.store (BaseAddr, VectorValue, VectorOfIndices,<br>Scale, Mask)<br>void @llvm.uindex.masked.store (BaseAddr, VectorValue, VectorOfIndices,<br>Scale, Mask)<br><br>Semantics:<br>For i=0,1,?,N-1: if (Mask[i]) {*(BaseAddr + VectorOfIndices[i]*Scale) =<br>VectorValue[i];}<br><br>VectorValue: any float or integer vector type.<br>BaseAddr: a pointer; may be zero if full address is placed in the index.<br>VectorOfIndices: a vector of i32 or i64 signed or unsigned integer values.<br>Scale: a compile time constant 1, 2, 4 or 8.<br>VectorValue, VectorOfIndices and Mask must have the same vector width.<br><br>An indexed store instruction with complete or partial overlap in memory<br>(i.e., two indices with same or close values) will provide the result<br>equivalent to serial scalar stores from least to most significant vector<br>elements.<br><br>The new intrinsics are common for all targets, like recently introduced<br>masked load and store.<br><br>Examples:<br><br><16 x float> @llvm.sindex.load.v16f32.v16i32 (i8 *%ptr, <16 x i32> %index,<br>i32 %scale)<br><16 x float> @llvm.masked.sindex.load.v16f32.v16i32 (i8 *%ptr, <16 x i32><br>%index, <16 x float> %passthru, <16 x i1> %mask)<br>void @llvm.sindex.store.v16f32.v16i64(i8* %ptr, <16 x float> %value, <16 x<br>164> %index, i32 %scale, <16 x i1> %mask)<br><br>Comments?<br><br>Thank you.<br><br><br>Elena<br><br><br><br><br><br>---------------------------------------------------------------------<br>Intel Israel (74) Limited<br><br>This e-mail and any attachments may contain confidential material for<br>the sole use of the intended recipient(s). Any review or distribution<br>by others is strictly prohibited. If you are not the intended<br>recipient, please contact the sender and delete all copies.<br><br><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br><br></blockquote><br><br><br>------------------------------<br><br>Message: 13<br>Date: Fri, 13 Mar 2015 09:52:30 +0100<br>From: John Criswell <jtcriswel@gmail.com><br>To: Kevin Hu <hxy9243@gmail.com><br>Cc: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Passing a function pointer as parameter to<br><span class="Apple-tab-span" style="white-space:pre"> </span>function call?<br>Message-ID: <5502A54E.20203@gmail.com><br>Content-Type: text/plain; charset="windows-1252"; Format="flowed"<br><br>Dear Kevin,<br><br>In the LLVM IR, the function and the pointer to the function are the <br>same thing. Within an LLVM pass, if you have a pointer to a Function <br>object:<br><br>Function * F = M.getOrInsertFunction(...)<br><br>... then you can use F as a parameter to a call instruction:<br><br>std::vector<Value *> args;<br>args.push_back (F);<br>CallInst * CI = CallInst::Create (AtExit, args, ...);<br><br>Regards,<br><br>John Criswell<br><br>On 3/12/15 11:24 PM, Kevin Hu wrote:<br><blockquote type="cite">Hi David,<br><br><br>Thanks very much.<br><br>I tried and the IR it produces is:<br><br>%call = call i32 @atexit(void ()* foo)<br><br>The problem is this still doesn't give me any clues how to produce the <br>code inside my LLVM pass. How do I get the pointer to this foo function?<br><br>Any hints?<br><br><br>Thank you.<br>Kevin Hu<br><br>On Thu, Mar 12, 2015 at 6:09 PM, David Blaikie <dblaikie@gmail.com <br><mailto:dblaikie@gmail.com>> wrote:<br><br> Easiest thing to do would be to write the equivalent C code, throw<br> it through Clang, and look at the IR it produces.<br><br> On Thu, Mar 12, 2015 at 3:00 PM, Kevin Hu <hxy9243@gmail.com<br> <mailto:hxy9243@gmail.com>> wrote:<br><br> Dear all,<br><br><br> I'm writing an LLVM pass, and I want to insert a call<br> instruction that takes a function pointer as a parameter. The<br> effect would be the same as following:<br><br> atexit(foo);<br><br> Where foo is a function I insert with M.getOrInsertFunction(),<br> which in LLVM is a Function class.<br><br> I searched for a while and did not come up with a satisfying<br> answer. Should I create a Value class of pointer type, or a<br> Int64Ty for a pointer? How do I get the pointer to the<br> function I create? I also tried passing foo as Function* in<br> LLVM as parameter to create CallInst directly, and I doesn't<br> seem to work.<br><br> Any hints and enlightenment is appreciated. Many thanks.<br><br><br> Regards,<br> Yours,<br> Kevin Hu<br><br> _______________________________________________<br> LLVM Developers mailing list<br> LLVMdev@cs.uiuc.edu <mailto:LLVMdev@cs.uiuc.edu><br> http://llvm.cs.uiuc.edu<br> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br><br><br><br><br><br>-- <br>Yours,<br>X. Hu<br><br><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br></blockquote><br><br>-- <br>John Criswell<br>Assistant Professor<br>Department of Computer Science, University of Rochester<br>http://www.cs.rochester.edu/u/criswell<br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150313/fac9240c/attachment-0001.html><br><br>------------------------------<br><br>Message: 14<br>Date: Fri, 13 Mar 2015 10:53:58 +0100<br>From: Thomas Rubiano <rubiano@lipn.univ-paris13.fr><br>To: Sanjoy Das <sanjoy@playingwithpointers.com><br>Cc: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] CFG Customization<br>Message-ID: <5502B3B6.1020004@lipn.univ-paris13.fr><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>Hi,<br><br>thank for your advice.<br><br>This is what I've already done for testing.<br><br>I thought there is a better way to do that using LLVM structures.<br>The goal is to reuse some functionalities offers by GraphTraits<NodeType>.<br>For instance, I would use GraphWriter, DOTGraphTraits etc... to see my <br>graph.<br><br>I want to do it very properly, I think a hashtable will not be enough, <br>right ?<br><br>Sorry again if I was not clear ...<br><br>Regards<br><br>Le 12/03/2015 22:14, Sanjoy Das a ?crit :<br><blockquote type="cite">Why not have a hastable mapping llvm::BasicBlock pointers to whatever<br>metadata you want to track per block?<br><br>On Thu, Mar 12, 2015 at 7:53 AM, rubiano <rubiano@lipn.univ-paris13.fr> wrote:<br><blockquote type="cite">Hi John, thank you for your answer.<br><br>Sorry if I was not clear ^^'<br><br>I try to build a RCG (Resource Control Graph) which is a CFG with a weight.<br>In my case, this weight corresponds to the number of heap allocations.<br>Then I want to add this weight to each node (then basic block) of this<br>graph.<br><br>I think that a CFG is a GraphTraits<BasicBlock*> then I suppose that this<br>RCG will be<br>a GraphTraits<MyBasicBlock*><br>"MyBasicBlock" can be an object like BasicBlock with a weight. (inherited or<br>not?)<br><br>I think that with this kind of graph it will be easier to detect "non size<br>increasing"<br>functions or loops.<br><br>My question is : what is the best way to build this graph ?<br><br>Thanks again,<br><br>Thomas<br><br>Le 2015-03-12 15:12, John Criswell a ?crit :<br><br><blockquote type="cite">Dear Thomas,<br><br>If you can describe more clearly what you are trying to accomplish, it<br>would help people give better advice. As I don't have a clear idea of<br>what you're trying to do, I can't explain the best way to do it.<br><br>Regards,<br><br>John Criswell<br><br><br>On 3/12/15 12:41 PM, rubiano wrote:<br><blockquote type="cite">Hi all,<br><br>I'm discovering LLVM and I want to build a customized CFG with customized<br>nodes (here BasicBlocks).<br>Simply, the purpose is to enrich CFG with some other informations.<br>What is the best way to do that ?<br><br>Please, tell me if I'm wrong (I'm not familiar enough with c++) but I<br>understand that :<br>- CFG is a GraphTraits<BasicBlock*><br>- it's not allowed to inherit from BasicBlock (never seen in the project)<br><br>Maybe it's better to create a new class (like MachineBasicBlock) that<br>contains a pointer to its BasicBlock ?<br>But this option requires to rewrite similar lines of code, right ?<br><br>Thanks,<br><br>Thomas<br><br><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br></blockquote></blockquote><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br></blockquote></blockquote><br><br><br><br>------------------------------<br><br>Message: 15<br>Date: Fri, 13 Mar 2015 09:56:27 +0000<br>From: Renato Golin <renato.golin@linaro.org><br>To: Hal Finkel <hfinkel@anl.gov><br>Cc: Clang Dev <cfe-dev@cs.uiuc.edu>, LLVM Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] [cfe-dev] Commit message policy?<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAMSE1keS_t=mKuQpiLeZTzaUdeH-3hoQKe9kd6t12Tbg5LLqLw@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>On 12 March 2015 at 22:39, Hal Finkel <hfinkel@anl.gov> wrote:<br><blockquote type="cite">Can you please update the patch on http://reviews.llvm.org/D8197 so that we can see what it is you plan to commit?<br></blockquote><br>Damn, lots of comments on Phab and I got no notifications<br>whatsoever... I must check what the issue is, sorry about the noise.<br><br>cheers,<br>--renato<br><br><br>------------------------------<br><br>Message: 16<br>Date: Fri, 13 Mar 2015 12:06:34 +0100<br>From: Sebastian Dre?ler <sebastian.dressler@gmail.com><br>To: Tom Stellard <tom@stellard.net><br>Cc: "llvmdev@cs.uiuc.edu" <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Reminder 3.5.2 merge deadline is Monday, Mar 16<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Testers needed<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAMFrpd5q=C7nh-6tKNunuW07kscjo_M5j8XfZo=kJ4OKRjD0Gw@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>2015-03-12 23:04 GMT+01:00 Tom Stellard <tom@stellard.net>:<br><br><blockquote type="cite">Hi,<br><br>Just a reminder that testing for 3.5.2 will begin on Monday, Mar 16. If<br>you have any patches you want merged please send an email to the<br>relevant commits list and cc me and the code owner. If you have already<br>done this and are waiting for a response, please ping the thread.<br><br>As always we need testers, so let me know if you want to help with<br>testing.<br><br><br></blockquote>I'll take care about OS X.<br><br>Cheers,<br>Sebastian<br><br><br><blockquote type="cite">Thanks,<br>Tom<br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br><br></blockquote>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150313/17fc8c1d/attachment-0001.html><br><br>------------------------------<br><br>Message: 17<br>Date: Fri, 13 Mar 2015 11:16:22 +0000<br>From: Renato Golin <renato.golin@linaro.org><br>To: Tom Stellard <tom@stellard.net><br>Cc: LLVM Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Reminder 3.5.2 merge deadline is Monday, Mar 16<br><span class="Apple-tab-span" style="white-space:pre"> </span>- Testers needed<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAMSE1kfv6rhqHLS0K1joLp0D58_bmE7WeNZR2w_hdZcJPEeXLA@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>Testing on ARM and AArch64 as usual.<br><br>On 12 March 2015 at 22:04, Tom Stellard <tom@stellard.net> wrote:<br><blockquote type="cite">Hi,<br><br>Just a reminder that testing for 3.5.2 will begin on Monday, Mar 16. If<br>you have any patches you want merged please send an email to the<br>relevant commits list and cc me and the code owner. If you have already<br>done this and are waiting for a response, please ping the thread.<br><br>As always we need testers, so let me know if you want to help with<br>testing.<br><br>Thanks,<br>Tom<br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br></blockquote><br><br>------------------------------<br><br>Message: 18<br>Date: Fri, 13 Mar 2015 08:47:51 -0600<br>From: Jonathan Roelofs <jonathan@codesourcery.com><br>To: Daniel Dilts <diltsman@gmail.com>, Ahmed Bougacha<br><span class="Apple-tab-span" style="white-space:pre"> </span><ahmed.bougacha@gmail.com><br>Cc: LLVM Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Lifting ASM to IR<br>Message-ID: <5502F897.1080005@codesourcery.com><br>Content-Type: text/plain; charset="windows-1252"; format=flowed<br><br><br><br>On 3/12/15 8:14 PM, Daniel Dilts wrote:<br><blockquote type="cite">On Thu, Mar 12, 2015 at 6:33 PM, Ahmed Bougacha<br><ahmed.bougacha@gmail.com <mailto:ahmed.bougacha@gmail.com>> wrote:<br><br><blockquote type="cite">On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:<br><blockquote type="cite">Does there exist a tool that could lift a binary (assembly for some<br>supported target) to LLVM IR? If there isn't, does this seem like<br>something that would be feasible?<br></blockquote></blockquote><br> There's plenty of variations on the idea: Revgen/S2E, Fracture, Dagger<br> (my own), libcpu, several closed-source ones used by pentest shops,<br> some that use another representation before going to IR (say<br> llvm-qemu), and probably others still I forgot about.<br><br> Are you interested in a specific target / use case?<br><br><br>I was thinking something along the lines of lifting a binary into IR and<br>spitting it out for a different processor.<br></blockquote><br>This is going to be extremely difficult. Imagine for example how this <br>function would be compiled:<br><br> struct Foo {<br> void *v;<br> int i;<br> long l;<br> };<br><br> long bar(Foo *f) {<br> return f->l;<br> }<br><br>If we pick a particular target, and compile this function for that, then <br>'foo' will have some offset into the struct from which it loads 'l'. <br>This is easy because we know the sizes of the struct's members, and the <br>layout rules for structs on the target.<br><br>Now turn that around: given an offset into a struct for one target, <br>what's the offset into the same struct on another target? We're stuck <br>because we can't reconstruct from this offset what the sizes of v and i <br>are individually; all we have is their sum (and that doesn't even take <br>alignment issues into account). This is because when we're looking at <br>the binary we don't know, given that offset, that the two elements in <br>front of it are a void* and an int.<br><br>Now, you might think that: "well, okay we'll just use the offsets from <br>one target in the other target's binaries". But that isn't going to work <br>either: what if void* isn't the same size between the two targets? And <br>that's just the tip of the iceberg.<br><br>TL;DR: binary translation is a very difficult problem.<br><br><br>Jon<br><br><blockquote type="cite"><br>Or maybe a decompiling tool of some kind.<br><br><br><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br><br></blockquote><br>-- <br>Jon Roelofs<br>jonathan@codesourcery.com<br>CodeSourcery / Mentor Embedded<br><br><br>------------------------------<br><br>Message: 19<br>Date: Fri, 13 Mar 2015 10:32:54 -0500<br>From: Shankar Easwaran <shankare@codeaurora.org><br>To: Rafael Esp?ndola <rafael.espindola@gmail.com>,<span class="Apple-tab-span" style="white-space:pre"> </span>Rui Ueyama<br><span class="Apple-tab-span" style="white-space:pre"> </span><ruiu@google.com><br>Cc: llvmdev Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] On LLD performance<br>Message-ID: <55030326.7050203@codeaurora.org><br>Content-Type: text/plain; charset=windows-1252; format=flowed<br><br>On 3/12/2015 5:12 PM, Rafael Esp?ndola wrote:<br><blockquote type="cite"><blockquote type="cite">There are also odd stuffs such as COMDAT groups or<br>merge-not-by-name-but-by-content sections, that may complicate the model. (I<br>don't think about that yet.)<br></blockquote>For comdats (on ELF) you should be able to avoid even reading the bits<br>from subsequent files once a comdat of a given name has been found.<br></blockquote>Symbols are not resolved as part of reading. So this is not achievable <br>with lld.<br><br>Shankar Easwaran<br><br>-- <br>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br><br><br><br><br>------------------------------<br><br>Message: 20<br>Date: Fri, 13 Mar 2015 12:00:03 -0400<br>From: Rafael Esp?ndola <rafael.espindola@gmail.com><br>To: Shankar Easwaran <shankare@codeaurora.org><br>Cc: llvmdev Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] On LLD performance<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CAG3jRe+Lc-B2FDYNw6r9SMDBcWQovnpO3i5V7NJ6W5P4=Udv2g@mail.gmail.com><br>Content-Type: text/plain; charset=UTF-8<br><br>On 13 March 2015 at 11:32, Shankar Easwaran <shankare@codeaurora.org> wrote:<br><blockquote type="cite">On 3/12/2015 5:12 PM, Rafael Esp?ndola wrote:<br><blockquote type="cite"><blockquote type="cite"><br>There are also odd stuffs such as COMDAT groups or<br>merge-not-by-name-but-by-content sections, that may complicate the model.<br>(I<br>don't think about that yet.)<br></blockquote><br>For comdats (on ELF) you should be able to avoid even reading the bits<br>from subsequent files once a comdat of a given name has been found.<br></blockquote><br>Symbols are not resolved as part of reading. So this is not achievable with<br>lld.<br></blockquote><br>Looks like a design decision that might cost us some performance.<br><br>Cheers,<br>Rafael<br><br><br><br>------------------------------<br><br>Message: 21<br>Date: Fri, 13 Mar 2015 09:15:57 -0700<br>From: Daniel Dilts <diltsman@gmail.com><br>To: Jonathan Roelofs <jonathan@codesourcery.com><br>Cc: LLVM Dev <llvmdev@cs.uiuc.edu><br>Subject: Re: [LLVMdev] Lifting ASM to IR<br>Message-ID:<br><span class="Apple-tab-span" style="white-space:pre"> </span><CANgHf=xGNmY6koV7LtEn0LN8boP0Be92QMyncBjjjg50t5ukMA@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>On Fri, Mar 13, 2015 at 7:47 AM, Jonathan Roelofs <jonathan@codesourcery.com<br><blockquote type="cite">wrote:<br></blockquote><br><blockquote type="cite"><br><br>On 3/12/15 8:14 PM, Daniel Dilts wrote:<br><br><blockquote type="cite">On Thu, Mar 12, 2015 at 6:33 PM, Ahmed Bougacha<br><ahmed.bougacha@gmail.com <mailto:ahmed.bougacha@gmail.com>> wrote:<br><br><blockquote type="cite">On Thu, Mar 12, 2015 at 05:44:02PM -0700, Daniel Dilts wrote:<br><blockquote type="cite">Does there exist a tool that could lift a binary (assembly for some<br>supported target) to LLVM IR? If there isn't, does this seem like<br>something that would be feasible?<br></blockquote></blockquote><br> There's plenty of variations on the idea: Revgen/S2E, Fracture, Dagger<br> (my own), libcpu, several closed-source ones used by pentest shops,<br> some that use another representation before going to IR (say<br> llvm-qemu), and probably others still I forgot about.<br><br> Are you interested in a specific target / use case?<br><br><br>I was thinking something along the lines of lifting a binary into IR and<br>spitting it out for a different processor.<br><br></blockquote><br>This is going to be extremely difficult. Imagine for example how this<br>function would be compiled:<br><br> struct Foo {<br> void *v;<br> int i;<br> long l;<br> };<br><br> long bar(Foo *f) {<br> return f->l;<br> }<br><br>If we pick a particular target, and compile this function for that, then<br>'foo' will have some offset into the struct from which it loads 'l'. This<br>is easy because we know the sizes of the struct's members, and the layout<br>rules for structs on the target.<br><br>Now turn that around: given an offset into a struct for one target, what's<br>the offset into the same struct on another target? We're stuck because we<br>can't reconstruct from this offset what the sizes of v and i are<br>individually; all we have is their sum (and that doesn't even take<br>alignment issues into account). This is because when we're looking at the<br>binary we don't know, given that offset, that the two elements in front of<br>it are a void* and an int.<br><br>Now, you might think that: "well, okay we'll just use the offsets from one<br>target in the other target's binaries". But that isn't going to work<br>either: what if void* isn't the same size between the two targets? And<br>that's just the tip of the iceberg.<br><br>TL;DR: binary translation is a very difficult problem.<br></blockquote><br><br>I was afraid of something like that. I was thinking that translating<br>function calls would be an issue; I didn't think about data layout.<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20150313/236cfbb5/attachment.html><br><br>------------------------------<br><br>_______________________________________________<br>LLVMdev mailing list<br>LLVMdev@cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br><br><br>End of LLVMdev Digest, Vol 129, Issue 48<br>****************************************<br></blockquote></div><br></div></div></body></html>