Re: [DynInst_API:] dyninst lock_tramp_guard

[Bill Williams <bill@xxxxxxxxxxx>]

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?

--bw
________________________________________
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
>