Re: [DynInst_API:] dyninst lock_tramp_guard

[Bill Williams <bill@xxxxxxxxxxx>]

Marc--

If you allocate map as a variableExpr of type unsigned char* (or whatever type is contained in the buffer) rather than unsigned long, and then perform the same magic so that it contains the base of the buffer, you should be able to use it as an array and/or perform pointer math without needing any gymnastics to dereference its contents. Does that help?

--bw
________________________________________
From: Marc <marc@xxxxxxxxxxx>
Sent: Monday, March 26, 2018 11:40 AM
To: Bill Williams; dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] dyninst lock_tramp_guard

Hi Bill,

On 26.03.2018 17:58, Bill Williams wrote:
> I think the right thing here is to back up several steps because you've de-variabled something prematurely, in all likelihood.
>
> If you're trying to access a field in a structure or an element of an array, there are BPatch_variable and BPatch_type methods that will help you out while ensuring that you're still dealing with a variable. As soon as you've turned it into an arithmetic expression, we assume it's just a number and our type system is hostile towards treating arbitrary numbers as pointers--for what I hope are obvious reasons.
>
> Am I understanding the shape of the problem correctly, and does the above help?

the following description is not fully correct but a simplification.

I am doing a openBinary() with writeFile().

the program I am instrumenting has a 64kb buffer.
with some magic I can get that buffer by:

BPatch_variableExpr *map = appBin->malloc(*(appImage->findType("unsigned
long")), "map");
BPatch_constExpr map_ptr (map->getBaseAddr());
instArgs.push_back(&map_ptr);
BPatch_funcCallExpr instIncExpr(*instIncFunc, instArgs);
etc.

so that function I am inserting is doing the magic of finding that 64
buffer and writing the starting location into the map variable.

in the following part of the program I have to continiously read from
that buffer.
I did use a different BPatch_funcCallExpr for that, but the performance
is bad, too bad to be usable.

so thats why I am switching to arithExpr to makes things faster, and
yes, it is way, way faster.
with the current show stopper that I dont know how to read the specific
byte in that 64kb buffer I am calculating every time.

if there is no way to do that I have to go hardcore, write dummy
snippets, write the file, and then open the file with a second program
that just overwrites the dummy instructions with the necessary
instructions I need.
Which will then only work on x64 or until there is a change in dyninst
which will change the generated instructions.

that being said, it is an open source program which expands on an
existing one that is widely used already, and the speed increase I
expect from my effort will be around 30-50% - when its working.

Thanks!

Regards,
Marc



> ________________________________________
> From: Marc <marc@xxxxxxxxxxx>
> Sent: Friday, March 23, 2018 1:40 PM
> To: Bill Williams; dyninst-api@xxxxxxxxxxx
> Subject: Re: [DynInst_API:] dyninst lock_tramp_guard
>
> Hi Bill,
>
> thanks a lot, that was very helpful.
> I am in the middle of doing that and I am now stuck at one thing:
>
> I have a BPatch_arithExpr() result that is a number and represents a
> memory location in the instrumented program.
> Now I want to read the byte at that address. How do I do that?
>
> Thanks!
>
> Regards,
> Marc
>
> On 22.03.2018 17:31, Bill Williams wrote:
>> Marc--
>>
>> The common idiom here is something like the following:
>>
>> BPatch_variable my_data = BPatch_malloc(my_inst_data_t);
>> // initialize data
>> for(p: points)
>> {
>>   // extractField left as an exercise for the implementer
>>   BPatch_variableExpr data_for_point = extractField(my_data, p);
>>   BPatch_assignExpr assignment(data_for_point, value_for_point);
>>   insertSnippet(assignment, p);
>> }
>> BPatch_funcCallExpr print_summary(summary_func, BPatch_Vector<BPatch_snippet>{my_data});
>> insertSnippet(print_summary, program_exit_point);
>>
>> where you build a data structure that can effectively be indexed by instpoint and record what you need, and then serialize your results at the end of execution. The simpler you can make the data structures and assignments, the faster the instrumented code will execute--but the more work you may need to do at summary time.
>>
>> --bw
>> ________________________________________
>> From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of Marc <marc@xxxxxxxxxxx>
>> Sent: Wednesday, March 21, 2018 9:14 PM
>> To: dyninst-api@xxxxxxxxxxx
>> Subject: Re: [DynInst_API:] dyninst lock_tramp_guard
>>
>> anwering myself:
>>
>> setTrampRecursive(true) and setSaveFPR(false) get the wished result :)
>>
>> In the documentation I find the note: "Write BPatch_snippet code that
>> avoids making function calls."
>>
>> so far I have only used it with function calls, and all snippets
>> elsewhere in code I saw - same same ... :)
>>
>> so, maybe anyone has a pointer on how to do that efficiently without
>> calling a function?
>>
>> Regards,
>> Marc
>>
>> On 22.03.2018 02:18, Marc wrote:
>>> Hi,
>>>
>>> I am instrumenting a binary, inserting various calls into it and saving
>>> it into a new file. (so, bpatch.openBinary(), walking through the basic
>>> blocks, using insertSnippet() where I want things)
>>>
>>> When I look at the newly saved file I notice that every snippit is
>>> preceded by DYNINST_lock_tramp_guard and followed by a
>>> DYNINST_unlock_tramp_guard.
>>>
>>> I know this is generally speaking a very good thing.
>>> But lets say that I know for 100% that in my target application that is
>>> an unneeded measure and hurts performance actually a lot.
>>> How can I disable it?
>>> Basically I would like that only the call to the function is in the
>>> location I want - plus pushing/poping the necessary registers.
>>>
>>> Thanks!
>>>
>>> Regards,
>>> Marc
>>> _______________________________________________
>>> Dyninst-api mailing list
>>> Dyninst-api@xxxxxxxxxxx
>>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>>
>> _______________________________________________
>> Dyninst-api mailing list
>> Dyninst-api@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>
>