Subject: RE: [rohc] Testing RFC 3485 state, bytecode loading in SigComp UD VM

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 11 Feb 2005 10:32:18 -0000

Hi All,

I've updated the torture tests draft with these tests and intend to submit
it on Monday morning.  Any comments before 9:00 GMT gratefully received
(comments received after that will have to wait for the next version).  The
draft is available at
<http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-torture-tests-00.txt
>.  

(Pekka, unfortunately I haven't had time to put these test cases through our
VM but will do so and let you know the outcome.)

Best regards,

Abbie

> -----Original Message-----
> From: Pekka Pessi [mailto:[email-masked]] 
> Sent: Monday, February 07, 2005 12:55 PM
> To: [email-masked]
> Subject: [rohc] Testing RFC 3485 state, bytecode loading in 
> SigComp UDVM
> 
> 
> Hello all,
> 
> I heard from Abigail that they are going to resurrect the SigComp
> user guide and torture tests documents. So, here are a couple of
> test cases for the torture test document. First simply accesses
> the SIP dictionary state, second one tests corner cases when
> saving bytecode. I'd appreciate feedback on the cases, especially
> if they do not work as expected.
> 
> --Pekka
> 
> ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--
> -8<---8<---8<---
> Accessing RFC 3485 State
> 
>    This section gives assembly code to test accessing SIP-SDP 
> shared state. 
>    The code first accesses the state and then outputs result.
> 
> 		at (32)
> 
> :input		pad (1)
> :input2		pad (1)
> :input3		pad (1)
> 
> 		at (128)
> 
> 		STATE-ACCESS (sip_dictionary, 20, 0xcfe, 1, input, 0)
> 		STATE-ACCESS (sip_dictionary, 6, 0xcff, 1, input2, 0)
> 		STATE-ACCESS (sip_dictionary, 12, 0xd00, 1, input3, 0)
> 
> 		OUTPUT (input, 3)
> 
> 		END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
> 
> :sip_dictionary
> 		byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
> 		byte (0xaa, 0x5a, 0xf2, 0xab, 0xb9, 0x14)
> 		byte (0xce, 0xaa, 0x05, 0xf9, 0x9c, 0xe6)
> 		byte (0x1b, 0xa5)
> 
>    The expected output of the code is 0x5349 50, and a total of 11
>    UDVM cycles are expected to be used. 
> 
>    Bytecode:
> 
>    0xf803 a11f a0a6 14ac fe01 2000 1fa0 a606 acff 0121 001f a0a6 0cad
>    0x0001 2200 2220 0323 0000 0000 0000 00fb e507 dfe5 e6aa 5af2 abb9 
>    0x14ce aa05 f99c e61b a5
> 
> --->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--
> ->8--->8--->8---
> 
> ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<--
> -8<---8<---8<---
> 
> Bytecode state creation 
>     
>    This section gives assembly code to test storing bytecode using
>    END-MESSAGE and later loading the bytecode using a partial
>    state identifier within the SigComp header. The assembly code
>    is designed so that it includes testing self-modifying byte
>    code, loading byte code in special memory areas, and correct
>    initialization order of the UDVM.
> 
>    1. Three items of bytecode state are created. 
>  
>    2. The bytecode is loaded using partial state identifier. 
> 
>    3. The bytecode is loaded using partial state identifier. 
> Part of the
>       loaded memory is reserved area, which is overwritten 
> after loading the
>       bytecode.
> 
>    4. The byte loading fails because partial state identifier 
> is too short.
> 
>  
> 	at (30)
> :save_area1
> 	set (saved_instr1, (save_area1 + (code_start2 - start_saved)))
> 
> 	at (80)
> :save_area2
> 	set (saved_instr2, (save_area2 + (code_start2 - start_saved)))
> 
> 	at (128)
> :code_start
> 	COPY (start_saved, saved_len, save_area1)
> 	set (modify1, (save_area1 + 5))
> 	LOAD (modify1, 0x1e03)
> 	STATE-CREATE (saved_len, save_area1, saved_instr1, 6, 10)
> 
> 	COPY (start_saved, saved_len, save_area2)
> 	STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10)
> 
> 	OUTPUT (ok1, 3)
> 
> 	END-MESSAGE (0, 0, saved_len, save_area2, saved_instr2, 12, 10)
> 	
> :ok1	byte (0x4f, 0x4b, 0x31)
> 
> 	set (saved_len, (end_saved - start_saved))
> 
> :start_saved
> 	byte (0x4f, 0x4b, 0x32)
> :code_start2
> 	; OUTPUT (save_area2, 3)
> 	byte (0x22, 0xa0, 0x50, 0x03)
> 	; END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
> 	byte (0x23)
> :end_saved
> 
> 
>    The expected output of the first message is 0x4f4b 31, and 
> a total of 50
>    UDVM cycles are expected to be used. 
> 
>    The second message consists of SigComp header and partial state
>    identifier: 0xfb24 63cd ff5c f8c7 6df6 a289 ff. The 
> expected output from
>    the second message is 0x4f4b 31, and a total of 5 UDVM cycles are
>    expected to be used.
> 
>    The third message consists of SigComp header and partial state
>    identifier: 0xf95b 4b43 d567 83. The expected output from
>    the third message is 0x0000 31, and a total of 5 UDVM cycles are
>    expected to be used.
>    
>    The fourth message consists of SigComp header and partial state
>    identifier: 0xf9de 8126 1199 1f. Loading of the bytecode 
> should fail
>    because the partial state ID length is too short (6, when 
> 20 bytes is
>    required).
> 
>    First message:
> 
>    0xf803 6112 a0ae 081e 0e23 be03 2008 1e21 060a 12a0 ae08 a050 2008
>    0xa050 a053 140a 22a0 ab03 2300 0008 a050 a053 0c0a 4f4b 314f 4b32
>    0x22a0 5003 23
> 
>    Second message:
> 
>    0xfbf8 07bf 971e f697 c3e3 5894 86
> 
>    Third message:
> 
>    0xf95b 4b43 d567 83
> 
>    Fourth message:
> 
>    0xf9de 8126 1199 1f
> 
> --->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--->8--
> ->8--->8--->8---
> 
> 
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc