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