<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div><blockquote type="cite"><div style="line-height: 1.4; margin: 10px; font-family: Arial, arial; font-size: 9pt;"><p style="margin-top: 5px; margin-bottom: 5px; font-size: 9pt;">- "since ABI says the stack pointer needs to be 8 byte aligned at function entry point" (taken from Manman's reply)</p><p style="margin-top: 5px; margin-bottom: 5px; font-size: 9pt;"> What will be considered as entry point here?</p><p style="margin-top: 5px; margin-bottom: 5px; font-size: 9pt;"> Is it place of SP Adjustments "sub sp, sp, #16"<br> (Or) Is it place of first user instruction(end of prologue) "ldr r2, .LCPI0_0"</p></div></blockquote></div><div style="margin-top: 0.8em; margin-bottom: 0.2em; font-family: Verdana, Tahoma, Arial, Helvetica, sans-serif; font-size: small; background-color: rgb(255, 255, 255);">Eight byte stack alignment is a requirement of the <a href="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/index.html" style="color: rgb(79, 15, 142); text-decoration: none;">Procedure Call Standard for the ARM Architecture [AAPCS]</a>. This specifies that functions must maintain an eight-byte aligned stack address (for example: <code class="aainlinemono" style="color: rgb(51, 51, 153); font-family: 'Lucida Sans Typewriter', 'Courier New', Courier, monospace; font-size: 0.9em;">0x00</code>, <code class="aainlinemono" style="color: rgb(51, 51, 153); font-family: 'Lucida Sans Typewriter', 'Courier New', Courier, monospace; font-size: 0.9em;">0x08</code>, <code class="aainlinemono" style="color: rgb(51, 51, 153); font-family: 'Lucida Sans Typewriter', 'Courier New', Courier, monospace; font-size: 0.9em;">0x10</code>, <code class="aainlinemono" style="color: rgb(51, 51, 153); font-family: 'Lucida Sans Typewriter', 'Courier New', Courier, monospace; font-size: 0.9em;">0x18</code>, <code class="aainlinemono" style="color: rgb(51, 51, 153); font-family: 'Lucida Sans Typewriter', 'Courier New', Courier, monospace; font-size: 0.9em;">0x20</code>) on all external interfaces. In practice this requirement is met if:</div><ul style="margin-top: 0.8em; margin-bottom: 0.2em; font-family: Verdana, Tahoma, Arial, Helvetica, sans-serif; font-size: small; background-color: rgb(255, 255, 255);"><li style="margin-top: 0.6em; margin-bottom: 0.2em;">At each external interface, the current stack pointer (SP) is a multiple of eight bytes.</li><li style="margin-top: 0.6em; margin-bottom: 0.2em;">Your OS maintains eight-byte stack alignment on its external interfaces, for example, on task switches</li></ul><div><br></div><div><div><-- from web</div><div><br></div><div>Manman</div><div><br><div><div>On Jun 20, 2013, at 5:35 AM, Rajesh Viswabramana <<a href="mailto:rajesh.vis@samsung.com">rajesh.vis@samsung.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="line-height: 1.4; margin: 10px; font-family: Arial, arial; font-size: 9pt; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">Hi All,</p><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">I tested earlier with llvm svn 3.3 release source.</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">Today I built and tested again with svn trunk, I also got "ldr r1, [r11, #80]", which solves the failure.</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">Thanks for all comments.</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">It seems similar issue<span class="Apple-converted-space"> </span><a href="http://llvm.org/bugs/show_bug.cgi?id=15868">http://llvm.org/bugs/show_bug.cgi?id=15868</a>, fixed already. </p><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">I have few queries, Just to get my understandings better. Could you please comment on these,</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">- "since ABI says the stack pointer needs to be 8 byte aligned at function entry point" (taken from Manman's reply)</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> What will be considered as entry point here?</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> Is it place of SP Adjustments "sub sp, sp, #16"<br> (Or) Is it place of first user instruction(end of prologue) "ldr r2, .LCPI0_0"</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">- What considerations will be made from llvm side to make abi compatibile with gcc/other compilers for arm - struct byval size >64 bytes.</p><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">Regards,<br>Rajesh</p><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;">-------<span class="Apple-converted-space"> </span><b>Original Message</b><span class="Apple-converted-space"> </span>-------</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"><b>Sender</b><span class="Apple-converted-space"> </span>: Stepan Dyatkovskiy<<a href="mailto:stpworld@narod.ru">stpworld@narod.ru</a>></p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"><b>Date</b><span class="Apple-converted-space"> </span>: Jun 20, 2013 03:08 (GMT+09:00)</p><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"><b>Title</b><span class="Apple-converted-space"> </span>: Re: [LLVMdev] ARM struct byval size > 64 triggers failure</p><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div>Hi Rajesh,<br><br>I'm in some stage of looking what exactly happens. As Manman mentioned<span class="Apple-converted-space"> </span><br>r0 is reserved for function return. Though, perhaps somewhere we didn't<span class="Apple-converted-space"> </span><br>catch that...<br><br>Would you tell me, please, your llvm revision number?<br><br>-Stepan<br><br>Manman Ren wrote:<br>><br>> I missed that the testing case is returning a struct.<br>> You are right in VARegSaveSize.<br>><br>> For callee:<br>> subsp, sp, #16<br>> push{r11, lr}<br>> movr11, sp<br>> subsp, sp, #8<br>> strr3, [r11, #20]<br>> strr2, [r11, #16]<br>> strr1, [r11, #12]<br>> ldrr1, [r11, #76]<br>><br>> The beginning of the input struct @ sp_at_entry - 16 - 8 + 12 =<br>> sp_at_entry -12<br>> # of leftover bytes 67-12 = 55<br>> r11+76 is @ sp_at_entry - 24 + 76 = sp_at_entry + 52, this is incorrect,<br>> it should be at align(55, 4) = 56.<br>><br>> For caller:<br>> movr0, sp<br>> ldrr1, .LCPI1_0<br>> strr1, [r0, #56]<br>><br>> the 2nd argument is at sp_at_entry + 56, which is correct.<br>><br>> On my setup (built from TOT), I got "ldr r1, [r11, #80]" instead of 76.<br>><br>> Thanks,<br>> Manman<br>><br>> On Jun 18, 2013, at 11:31 PM, Rajesh Viswabramana wrote:<br>><br>>> Hi all,<br>>><br>>><br>>> Thanks for all comments,<br>>><br>>> Filed bug report with details,<br>>><br>>> <a href="http://llvm.org/bugs/show_bug.cgi?id=16368">http://llvm.org/bugs/show_bug.cgi?id=16368</a><br>>><br>>> @Manman, please find comments, queries inline.<br>>><br>>><br>>> Regards,<br>>> Rajesh<br>>><br>>><br>>> -------*Original Message*-------<br>>><br>>> *Sender*: Stepan Dyatkovskiy<stpworld@narod.ru>><br>>><br>>> *Date*: Jun 19, 2013 05:15 (GMT+09:00)<br>>><br>>> *Title*: Re: [LLVMdev] ARM struct byval size > 64 triggers failure<br>>><br>>><br>>> Hi all,<br>>> One more interesting job :-)<br>>> I'll look too at this case tomorrow. Today my brain is about to be<br>>> exploded..<br>>> -Stepan.<br>>> 18.06.2013, 22:56, "Manman Ren"<span class="Apple-converted-space"> </span><mren@apple.com><mailto:mren@apple.com="">>:<br>>>> Hi Rajesh,<br>>>> The callee code looks okay to me<br>>>>><br>>>>> Assembly for check114<br>>>>> ---------------------------------------------------------------<br>>>>> sub sp, sp, #16<br>>>>> push {r11, lr}<br>>>>> mov r11, sp<br>>>>> sub sp, sp, #8<br>>>>> str r3, [r11, #20]<br>>>>> str r2, [r11, #16]<br>>>>> str r1, [r11, #12]<br>>>>> ldr r1, [r11, #76]<br>>>>><br>>>> VARegSaveSize is 16 because we store the first 16 bytes of struct<br>>>> byval in r0 to r3.<br>>>> For the test code/assembly I mentioned, only r1-r3 are used for<br>>>> struct byval. r0 used for return val.<br>>>><br>>>> So, NumGPRs = 3, VARegSize = 12, VARegSaveSize =16(4 byte offset),<br>>>> access of arg1 is going wrong.<br>>>><br>>>> For updated test code:<br>>>><br>>>> struct S114 check114 (*int a*, struct S114 arg0, struct S114* arg1) {<br>>>><br>>>> .....<br>>>> }<br>>>><br>>>> Only r1, r2 used for struct byval, NumGPRs = 2, VARegSize = 8,<br>>>> VARegSaveSize =8, this case works, able to access arg1.<br>>>><br>>>><br>>>> Please correct me, if my above understanding is wrong about NumGPRs,<br>>>> VARegSaveSize calculation.<br>>>><br>>>><br>>>> Align in computeRegArea is 8 since ABI says the stack pointer needs<br>>>> to be 8 byte aligned at function entry point.<br>>>> But the second argument does not have to be 8 byte aligned, in fact<br>>>> it is 4 byte aligned for i32.<br>>>> Ok.<br>>>> r11, #76 is equivalent to sp_at_entry + 52 since r11 = spat_entry -<br>>>> 16 - 8, which is 4-byte aligned after<br>>>> storing the leftover (67-16=51) bytes of struct byval.<br>>>> For test code, 3 reg used for struct byval, left over will be (67- 12<br>>>> = 55) copied to stack by caller, 55 sets of ldrb,strb in assembly.<br>>>> Pasting dump again for locating arg1 from sp_at_entry,<br>>>> @entry of check114<br>>>> sp 0xbefff808 0xbefff808 --> sp_at_entry<br>>>><br>>>> At arg1 accessing instruction [0xbefff808 + 52] -><br>>>> [0xbefff83c] ->*0x4071706f*<br>>>> 0xbefff7e4: 0x4001ed08 0x40024f90 0x4071706f 0xbefff8a0<br>>>> 0xbefff7f4: 0x0000869c 0x00000000 0x3231302f 0x36353433<br>>>> 0xbefff804: 0x3a393837 0x3e3d3c3b 0x4241403f 0x46454443<br>>>> 0xbefff814: 0x4a494847 0x4e4d4c4b 0x5251504f 0x56555453<br>>>> 0xbefff824: 0x5a595857 0x5e5d5c5b 0x6261605f 0x66656463<br>>>> 0xbefff834: 0x6a696867 0x6e6d6c6b* 0x4071706f* *0x00010861*<br>>>><br>>>> Can you also paste the assembly for the caller side and check whether<br>>>> the second argument is stored<br>>>> at sp_at_entry+52?<br>>>> Please find the attached assembly file.<br>>>> As Renato suggested, please file a bug report.<br>>>> Filed bug.<br>>>> Thanks,<br>>>> Manman<br>>>> On Jun 18, 2013, at 4:26 AM, Rajesh Viswabramana<br>>>><span class="Apple-converted-space"> </span><rajesh.vis@samsung.com><mailto:rajesh.vis@samsung.com="">> wrote:<br>>>><br>>>>> Hi,<br>>>>><br>>>>> Handling of pass by val of struct size >64 bytes case is seems wrong<br>>>>> for arm targets.<br>>>>><br>>>>><br>>>>> *Summary:*<br>>>>><br>>>>> Incase of struct pass by value for size > 64 along with other<br>>>>> function params, failure seen in some corner cases. Access to<br>>>>> function params result in wrong stack location access.<br>>>>><br>>>>> Stack pointer adjustment done by prologue emitter and offset used to<br>>>>> access function params have different logics for calculaton.<br>>>>><br>>>>><br>>>>> *Test code<br>>>>> *---------------------------------------------------------------<br>>>>> #include<span class="Apple-converted-space"> </span><stdio.h><br>>>>> struct S114 {<br>>>>> char a[67];<br>>>>> }a114[5];<br>>>>><br>>>>> struct S114 check114 (struct S114 arg0, struct S114* arg1) {<br>>>>> if(&a114[0] != arg1) // arg1 value is wrong<br>>>>> printf( "values %p, %p\n", &a114[0], arg1);<br>>>>> }<br>>>>> int main () {<br>>>>> int i= 0, j = 0;<br>>>>> for (;j<2; j++) // just filling<br>>>>> a114 with some values for identification<br>>>>> for(i=0; i<sizeof(struct s114);="" i++)=""><br="">>>>> memset(&a114[j].a[i],(0x11+i+j*30), sizeof(int));<br>>>>><br>>>>> check114 (a114[1], &a114[0]); //=> a114[0] is accessed<br>>>>> from wrong location inside check114 function<br>>>>> }<br>>>>> ---------------------------------------------------------------<br>>>>> clang -v<br>>>>> clang version 3.3 (tags/RELEASE_33/final)<br>>>>> Target: i386-pc-linux-gnu<br>>>>> Thread model: posix<br>>>>><br>>>>> *Output on arm :<br>>>>> *# ./check114.exe<br>>>>> values 0x10861, 0x4071706f<br>>>>> which is wrong.<br>>>>><br>>>>> Assembly for check114<br>>>>> ---------------------------------------------------------------<br>>>>> sub sp, sp, #16<br>>>>> push {r11, lr}<br>>>>> mov r11, sp<br>>>>> sub sp, sp, #8<br>>>>> str r3, [r11, #20]<br>>>>> str r2, [r11, #16]<br>>>>> str r1, [r11, #12]<br>>>>> ldr r1, [r11, #76]<br>>>>> str r1, [sp, #4]<br>>>>> .loc 1 7 0 prologue_end<br>>>>> ldr r2, .LCPI0_0<br>>>>> cmp r2, r1<br>>>>> beq .LBB0_2<br>>>>> b .LBB0_1<br>>>>> ---------------------------------------------------------------<br>>>>><br>>>>> From reg, stack dump:<br>>>>> ------------------------------------------------------------------------------------------------------------------------------<br>>>>> @entry of check114<br>>>>> => 0x8398<span class="Apple-converted-space"> </span><check114>: sub sp, sp, #16<br>>>>> 0x839c<span class="Apple-converted-space"> </span><check114+4>: push {r11, lr}<br>>>>> sp 0xbefff808 0xbefff808<br>>>>><br>>>>> @if condition<br>>>>> 0x83b4<span class="Apple-converted-space"> </span><check114+28>: ldr r1, [r11, #76] ; 0x4c <---<br>>>>> wrong value copied to r1, offset #76 should be #80<br>>>>> 0x83b8<span class="Apple-converted-space"> </span><check114+32>: str r1, [sp, #4]<br>>>>> 0x83bc<span class="Apple-converted-space"> </span><check114+36>: ldr r2, [pc, #44] ; 0x83f0<span class="Apple-converted-space"> </span><check114+88><br>>>>> => 0x83c0<span class="Apple-converted-space"> </span><check114+40>: cmp r2, r1<br>>>>><br>>>>> r11 0xbefff7f0 -1090521104<br>>>>> sp 0xbefff7e8 0xbefff7e8<br>>>>><br>>>>> Stack dump:<br>>>>> 0xbefff7e4: 0x4001ed08 0x40024f90 0x4071706f 0xbefff8a0<br>>>>> 0xbefff7f4: 0x0000869c 0x00000000 0x3231302f 0x36353433<br>>>>> 0xbefff804: 0x3a393837 0x3e3d3c3b 0x4241403f 0x46454443<br>>>>> 0xbefff814: 0x4a494847 0x4e4d4c4b 0x5251504f 0x56555453<br>>>>> 0xbefff824: 0x5a595857 0x5e5d5c5b 0x6261605f 0x66656463<br>>>>> 0xbefff834: 0x6a696867 0x6e6d6c6b* 0x4071706f*<br>>>>> *0x00010861* //[R11+4c] -> [0xbefff7f0+4c] -><br>>>>> [0xbefff83c] -> 0x4071706f<br>>>>><br>>>>> Correct value is at location {[R11+4c]*+4*} --> 0x00010861, 4 bytes<br>>>>> offset going wrong.<br>>>>> ------------------------------------------------------------------------------------------------------------------------------<br>>>>><br>>>>> When i checked from the ARM Lowering part for generation of<br>>>>> sub sp, sp, #16<br>>>>><br>>>>> Emitted by,<br>>>>><br>>>>> if (VARegSaveSize)<br>>>>> emitSPUpdate(isARM, MBB, MBBI, dl, TII, -VARegSaveSize,<br>>>>> // --> VARegSaveSize is calculated in computeRegArea<br>>>>> MachineInstr::FrameSetup)<br>>>>><br>>>>> ARMTargetLowering::computeRegArea(..) {<br>>>>> ...<br>>>>> VARegSize = NumGPRs * 4;<br>>>>> VARegSaveSize = (VARegSize + Align - 1) & ~(Align -<br>>>>> 1); // --> 8 byte alignment done here<br>>>>> }<br>>>>><br>>>>> Stack pointer decremented to NumGPRs*4 + alignment<br>>>>><br>>>>> NumGPRs = 3 registers<br>>>>><br>>>>> VARegSaveSize = 16 (after considering 8 byte alignment )<br>>>>><br>>>>><br>>>>> When the offset(#76) for the instruction, "ldr r1, [r11, #76] ;<br>>>>> 0x4c" is calculated, 4 bytes alignment is considered.<br>>>>> In prologue stackpointer calculation 8 byte alignment is considered.<br>>>>><br>>>>> Due to this mimatch of alignment, If try to access any parameter<br>>>>> after byval which results wrong value.<br>>>>><br>>>>> Issue(or offset of 4 bytes) wont occur if even number of register<br>>>>> used for byval spilling.<br>>>>> ex:<br>>>>> struct S114 check114 (int a, struct S114 arg0, struct S114* arg1) {<br>>>>> // accessing arg1 is fine in this case<br>>>>> .....<br>>>>> }<br>>>>><br>>>>> Could someone comment on below queries about fixing the problem,<br>>>>><br>>>>> 1) Is this 8 byte alignment mandatory ? Is this due to " ARM AAPCS<br>>>>> 5.2.1.2 Stack constraints at a public interface" ? Can this be removed?<br>>>>><br>>>>> 2) We will leave alignment as it is but in prologue we will adjust<br>>>>> SP once again, this is little meaningless.<br>>>>><br>>>>> 3) While accessing arg1 we will consider alignment and add extra<br>>>>> offset -> looks better.<br>>>>><br>>>>> Offset to access arg1 is calculated by selection DAG that will be<br>>>>> target independent. But Alignment adjustment should be done by<br>>>>> target lowering. Any suggestions on how to fix this ?<br>>>>><br>>>>> Regards,<br>>>>> Rajesh<br>>>>><br>>>>> <201306181656803_BEI0XT4N.gif><br>>>>><br>>>>> _______________________________________________<br>>>>> LLVM Developers mailing list<br>>>>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><br>>>>><span class="Apple-converted-space"> </span><mailto:llvmdev@cs.uiuc.edu><a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br>>>>><span class="Apple-converted-space"> </span><http: llvm.cs.uiuc.edu=""><br>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br>>>> ,<br>>>><br>>>> _______________________________________________<br>>>> LLVM Developers mailing list<br>>>><span class="Apple-converted-space"> </span><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a><br>>>><span class="Apple-converted-space"> </span><mailto:llvmdev@cs.uiuc.edu><a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br>>>><span class="Apple-converted-space"> </span><http: llvm.cs.uiuc.edu=""><br>>>><span class="Apple-converted-space"> </span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>>>><br>>><br>>><br>>><br>>><br>>><br>>><br>>> <201306191201558_BEI0XT4N.gif><br>>><br>>><span class="Apple-converted-space"> </span><check114.s><br>><br><br><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div></check114.s></http:></mailto:llvmdev@cs.uiuc.edu></http:></mailto:llvmdev@cs.uiuc.edu><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><div style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"> <br class="webkit-block-placeholder"></div><table id="confidentialsignimg"><tbody><tr><td namo_lock="" style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"><p style="margin-top: 5px; font-family: Arial, arial; margin-bottom: 5px; font-size: 9pt;"><span><201306201804240_BEI0XT4N.gif></span></p></td></tr></tbody></table></check114+40></check114+88></check114+36></check114+32></check114+28></check114+4></check114></br=""></sizeof(struct></stdio.h></mailto:rajesh.vis@samsung.com=""></rajesh.vis@samsung.com></mailto:mren@apple.com=""></mren@apple.com></stpworld@narod.ru></div></blockquote></div><br></div></div></body></html>