On 19/11/09 23:29 -0800, Sukadev Bhattiprolu wrote:
> Louis Rilling [[email protected]] wrote:
> | > 
> | >         __asm__ __volatile__(
> | >                  "syscall\n\t"  /* Linux/x86_64 system call */
> | >                  "testq %0,%0\n\t"      /* check return value */
> | >                  "jne 1f\n\t"           /* jump if parent */
> | >                  "popq %%rbx\n\t"       /* get subthread function */
> | >                  "call *%%rbx\n\t"      /* start subthread function */
> | >                  "movq %2,%0\n\t"
> | >                  "syscall\n"            /* exit system call: exit 
> subthread */
> | >                  "1:\n\t"
> | >                  "popq %%rbp\t"         /* restore parent's ebp */
> | >                 :"=a" (retval)
> | >                 :"0" (__NR_clone3), "i" (__NR_exit)
> | >                 :"ebx", "ecx", "edx"
> | >                 );
> | 
> | 2. You should probably not separate this into two asm statements. In 
> particular,
> |    the compiler has no way to know that r10 should be preserved between the 
> two
> |    statements, and may be confused by the change of rsp.
> | 
> 
> Don't know enough asm, but can we leave them as two asm statements if we
> add all registers with parameters to the clobbered list ? The i386 code that
> Dave is referring to adds 3 (%ebx, %ecx, %edx) to the clobbered list, but is
> the missing the fourth, %edi.

No. Nothing prevents the compiler from instrumenting the code and overwriting
registers between the two statements. Moreover I don't see the point of
separating this in two statements. To me it looks weird to separate input
registers setup from syscall call.

The clobbered list just lets the compiler know that those registers may be
overwritten by the asm instructions, so that the compiler should not rely on the
contents of those registers after the asm statement. But as soon as the
statement is executed, the compiler can use the clobbered registers again.

Louis

> 
> Sukadev
> 
> | 3. r10 and r11 should be listed as clobbered.
> | 
> | 4. I fail to see the magic that puts the subthread function pointer in the
> |    stack.
> | 
> | 5. Maybe rdi should contain the subthread argument before calling the 
> subthread?
> | 
> | 6. rdi, rsi, rdx, rcx, r8 and r9 should be added to the clobber list 
> because of
> |    the call to the subthread function.
> | 
> | 7. rsi could be used in place of rbx to hold the function pointer, which 
> would
> |    allow you to remove ebx from the clobber list.
> | 
> | 8. I don't see why rbp should be saved. The ABI says it must be saved by the
> |    callee.
> | 
> | 9. Before calling exit(), maybe put some exit code in rdi?
> | 
> | > 
> | >         if (retval < 0) {
> | >                 errno = -retval;
> | >                 retval = -1;
> | >         }
> | >         return retval;
> | > }
> | 
> | Thanks,
> | 
> | Louis
> | 
> | [...]
> | 
> | -- 
> | Dr Louis Rilling                    Kerlabs
> | Skype: louis.rilling                        Batiment Germanium
> | Phone: (+33|0) 6 80 89 08 23                80 avenue des Buttes de Coesmes
> | http://www.kerlabs.com/                     35700 Rennes
> 
> 
> 
> | _______________________________________________
> | Containers mailing list
> | [email protected]
> | https://lists.linux-foundation.org/mailman/listinfo/containers
> _______________________________________________
> Containers mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/containers

-- 
Dr Louis Rilling                        Kerlabs
Skype: louis.rilling                    Batiment Germanium
Phone: (+33|0) 6 80 89 08 23            80 avenue des Buttes de Coesmes
http://www.kerlabs.com/                 35700 Rennes

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel

Reply via email to