[llvm-dev] Custom Binary Format Challenges

Brenda So via llvm-dev llvm-dev at lists.llvm.org
Sun Apr 1 15:00:52 PDT 2018


Hi Kenneth,

Can you elaborate what you mean by instruction pointer value? Like the
actual instruction with opcode and operands? With the sample code that I
showed you, the instrucrtion pointer in the innermost for loop will have
access to the following functions:

http://llvm.org/doxygen/classllvm_1_1Instruction.html

Alternatively, you can use the dump() operation to dump the instructions
out.

Unfortunately I don't know how to address your second question. That's
stretching my knowledge in LLVM.

Brenda


On Sun, Apr 1, 2018 at 11:32 AM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> Thank you so much!
>
> What about discovering the instruction pointer value?
> Also, does anybody know how to embed an artifact as a resource in a
> binary? I'd like to have two text sections, and have one copied in from
> another binary.
>
> On Sun, Apr 1, 2018 at 2:15 PM, Brenda So <sogun3 at gmail.com> wrote:
>
>> Hi,
>>
>> You can write it as if you are writing an optimization pass:
>> http://llvm.org/docs/ProgrammersManual.html
>>
>> It sounds like your highest level is a module, hence you should write a
>> module pass. There is example code on LLVM Programmer's Manual on how to do
>> a function pass:
>>
>> Function* targetFunc = ...;
>> class OurFunctionPass : public FunctionPass {
>>   public:
>>     OurFunctionPass(): callCounter(0) { }
>>
>>     virtual runOnFunction(Function& F) {
>>       for (BasicBlock &B : F) {
>>         for (Instruction &I: B) {
>>           if (auto *CallInst = dyn_cast<CallInst>(&I)) {
>>             // We know we've encountered a call instruction, so we
>>             // need to determine if it's a call to the
>>             // function pointed to by m_func or not.
>>             if (CallInst->getCalledFunction() == targetFunc)
>>               ++callCounter;
>>           }
>>         }
>>       }
>>     }
>>
>>   private:
>>     unsigned callCounter;};
>>
>> Making the FunctionPass a Module pass should be pretty easy with the
>> linked guide. (instead of inheriting from Function Pass you can inherit
>> frmo module pass) Afterwards, you can build your new pass against your LLVM
>> source code and run it using the opt functionality.
>>
>> Hope I didn't misunderstood your question -- if you have anymore let me
>> know!
>>
>> Brenda
>>
>>
>>
>>
>>
>> On Sun, Apr 1, 2018 at 1:48 PM, Kenneth Adam Miller via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hello,
>>>
>>>
>>> I hope you are all doing well and thanks in advance. I need to program a
>>> transformation of a set of llvm bitcode to have some various techniques
>>> woven in. In particular, I need to resolve a given computed target address
>>> to one of several in the same way that the function of a dynamic library is
>>> resolved, but I need this resolution to happen in the binary target of my
>>> choice where I tell it to. It's basically exactly the same facility as when
>>> you compile a group of files as a shared library target. The only
>>> difference is, I need this to happen under my control, according to
>>> function targets that I can choose and for an argument value that I can
>>> also choose as an ordinal to look them up.
>>>
>>> I think that I may need to write a compiler pass where this occurs but
>>> part of the problem is 1) I don't know how to make such a thing occur at
>>> the bitcode level, 2) and the oridinal is calculated from the instruction
>>> pointer.
>>>
>>> Can anybody help? Is there a library or function call for calculating
>>> lookup tables from a given set of targets given an ordinal? Is there a way
>>> to obtain the instruction pointer in llvm bitcode?
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180401/b28a7a00/attachment.html>


More information about the llvm-dev mailing list