Re: [Valgrind-developers] cachegrind and vex-chase

[Christian B. <bor...@de...>]

On 06/23/2016 02:21 PM, Josef Weidendorfer wrote:
> Am 23.06.2016 um 13:11 schrieb Christian Borntraeger:
>> On 06/20/2016 11:39 PM, Josef Weidendorfer wrote:
>>> Am 20.06.2016 um 22:26 schrieb Christian Borntraeger:
>>>> Simple testcase with 2 branches, both are detected:
>>>>
>>>> # cat test.s
>>>> .globl _start
>>>> _start:
>>>> brasl 14,test # save next address into r14, call test
>>>> svc 1 # exit system call
>>>>
>>>> test:
>>>> br 14 # jump to r14
>>>
>>> What is the VEX IR both with/without chase value set to 0
>>> for this nice small example?
>>
>> Interestingly enough for this example no different can be seen
>> in the counts, but the IR differs.
>>
>>
>>>
>>> I would be interested to see the IR before and after
>>> instrumentation, ie. "--trace-flags=01100000".
>>
>> with --vex-guest-chase-thresh=0
>> ...
>> default:
>> ...
> 
> Hmm. Looks as expected.
> 
> It would be interesting to see the instrumentation added by cachegrind
> when branch simulation is switched on.

Sure, will do in a week as I am on my way into vacation ;-)
> 
> Perhaps off-topic:
> 
>> br       %r14
>>              ------ IMark(0x800000DC, 2, 0) ------
>>              PUT(336) = GET:I64(304)
>>              PUT(336) = GET:I64(336); exit-Return
> 
> How can the translation to VEX see that this is a Return?
> Is %r14 expected to save the return address according to the ABI?

Its tricky. There are no explicit return opcodes, but abi requires to have the
return address as r14 on function entry.
Of course gcc is free to shuffle things around in that function, so you can
see all kind of registers for return,e.g. a br %r4 at the end of the function. when
gcc spilled the r14 content on the stack and loaded the return into r4 before jumping
back.