[DiSL-user] Handling Array store/load

[Lubomír Bulej]

Hi Alessio,

if you implement it on ShadowVM, your solution might be just what the doctor
ordered -- if it works, I would leave it that way.

With the static context, you would be doing basically the same (possibly with
less overhead), but unless you are worried about overhead (which will be
significant on ShadowVM anyway), I would try do most of the work in the ShadowVM.

If you track GETFIELD and GETSTATIC in ShadowVM and use this information when
you see ALOAD/ASTORE, I think it should be fine.

Lubomir

On 03/05/17 07:53, Alessio Gambi wrote:
> Hi Lubomir,
> 
> great answer ! I’ll try to implement that ASAP.
> 
> For the record I describe below the (hacky) solution that I adopted so far, which is based on storing partial states information from array accesses (getfield and getstaticfield): 
> 
> when I observe a getField or a getStatic which refer to an array, I keep the reference of the array inside a temporary variable, 
> that I use later on. The time I observe the first ASTORE I raise the event that the array was modified and clear the temporary variable.
> If I observe an ALOAD instead, I raise the event that the array element was read and clear the temporary variable.
> 
> — Alessio
> 
> 
> Alessio Gambi, Ph.D.
> gambi at st.cs.uni-saarland.de
> 
> 
>> On 02 May 2017, at 22:47, Lubomír Bulej <lubomir.bulej at d3s.mff.cuni.cz> wrote:
>>
>> Hi Alessio,
>>
>> when you instrument the array store bytecodes, the information you need is not
>> directly available, because the array access bytecodes (?ASTORE, ?ALOAD) work
>> with the array reference on stack -- the reference could have been left there
>> after a function all, or obtained using the GETFIELD or GETSTATIC bytecodes --
>> the information on the class is only available those.
>>
>> To do it properly, you would need to do a simple evaluation of the method's
>> bytecode to trace how values got on the stack and which array references you
>> use with the ?ASTORE and ?ALOAD bytecodes.
>>
>> As a simpler solution, you could try to scan the method bytecode backwards
>> from the point of the ?ASTORE or ?ALOAD bytecode and try to find the first
>> GETFIELD or GETSTATIC bytecode that fetches an array (or a method invocation
>> that returns the array), i.e., the source of the array reference, and then
>> fetch the owner and the field name from that instruction.
>>
>> This would be done in a custom static context, i.e., a class that implements
>> the StaticContext interface.
>>
>> I would suggest to look at the InstructionStaticContext implementation in the
>> trunk version, where you will find the getIndex() method, which returns the
>> index of an instruction's bytecode in a method. It only counts "real" bytecode
>> instructions (not all ASM's AbstractInsnNode which are also used for labels).
>>
>> The InstructionStaticContext extends the AbstractStaticContext class (which
>> does not really do much at the moment, there are plans to make this interface
>> nicer). Within the getIndex() method, the staticContextData.getRegionStart()
>> gets you the start of the region the context is related to. The instruction
>> nodes are linked, so you could try to walk back the list of instructions to
>> find the field load that got the array reference on top of the stack and
>> check the FieldAccessStatic context on how to retrieve the owner class and
>> field name.
>>
>>
>> Best regards,
>> Lubomir
>>
>>
>>
>>
>> On 28/04/17 12:15, Alessio Gambi wrote:
>>> Hi DiSL-ers,
>>>
>>> I am in the following situation:
>>>
>>> I can capture the array store and load events, but I cannot understand how I can get the following information (if possible):
>>>
>>> - Which field of which class the array store refers to?
>>>
>>> Best
>>>
>>> — Alessio
>>> _______________________________________________
>>> Disl-user mailing list
>>> Disl-user at d3s.mff.cuni.cz
>>> https://d3s.mff.cuni.cz/mailman/listinfo/disl-user
>>>
> 

-- 
Dept. Dist. and Dependable Systems
Faculty of Mathematics and Physics
Charles University, Czech Republic
Web: http://d3s.mff.cuni.cz
Tel: +420-221914267