asmtools bug: ldc constant dynamic that returns a long or a double should use ldc2_w instead of ldc

forax at univ-mlv.fr forax at univ-mlv.fr
Tue Sep 4 19:22:38 UTC 2018


Thanks Lois, thanks Leonid,
your right, i should have used ldc2_w instead of ldc in my test,
so my bad, it's not a bug, i've not fully understood how asmtools works.

many thanks,
Rémi 

----- Mail original -----
> De: "leonid kuskov" <Leonid.Kuskov at Oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Mardi 4 Septembre 2018 21:19:12
> Objet: Re: asmtools bug: ldc constant dynamic that returns a long or a double should use ldc2_w instead of ldc

> Hi Remi,
> 
> Many thanks for reporting the issue. I consider that the asmtools
> behavior is correct.
> The main goal of asmtools is the ability to generate a broken binary
> code. asmtools just converts stuff that it processes.
> It will be impossible to develop negative test cases if the tool
> controls a return type and overwrites a corresponding instruction.
> For example, I need to check a negative test cases: how VM will process
> pairs ldc2_w:bsm(...)I,  ldc_w:bsm(...)D?
> Here correction of instructions will hide an expected VM reaction.
> 
> Thanks,
> Leonid
> 
> On 9/2/18 07:40, Remi Forax wrote:
>> Hi all, hi Leonid,
>> while fixing a bug in ASM [1] when a ldc to a condy that returns a long uses the
>> wrong bytecode,
>> i've discovered that autotools has the same issue.
>>
>> The following code should generate a ldc2_w and not a ldc.
>>
>> public static Method primitiveExample:"()J"
>>    stack 2 locals 0
>> {
>>      ldc  Dynamic REF_invokeStatic
>>          :jdk11/AllInstructions.bsm
>>          :"(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/Class;)J"
>>          :_
>>          :"J" {};
>>      lreturn;
>> }
>>
>> in case you wonder why we use asmtools, for testing ASM we try to not use
>> bytecodes generated by ASM as source :)
>>
>> regards,
>> Rémi
>>
> > [1] https://gitlab.ow2.org/asm/asm/issues/317850



More information about the valhalla-dev mailing list