well, i think that earlier nils or bill mentioned that glibc on linux might have a fallback mode to use int80 instead of syscall. my first recommendation would be that if you could get this activated it might make things a lot easier.
otherwise, if you want to support the syscall instruction for system calls, the first thing i think you'll have to figure out a mechanism for the kernel to be able to differentiate between linux calls and solaris calls. ie, if the kernel gets invoked for system call 5, how does it know if the system call was made by some linux code (in which case you need to jump out back to userland to do emulation) or if the system call was made by some native solaris code running in the linux process and doing emulation of linux system calls (in which case the system call should just be passed on through. i've though about this a bit and have some ideas about how it could be done. let me know if you're interested in hearing them. perhaps others can comment on if there are more pressing important issues with the syscall interfaces that i might be missing. ed On Mon, May 07, 2007 at 06:26:31PM +0800, Wei Shen wrote: > Hi, > > I did some investigation and think the first two main tasks to support Linux > x64 are system call emulation and ELF binary execution. > > The 64-bit glibc in Centos3 x64 uses the *syscall* instruction to invoke > Linux system calls, while the 32-bit glibc still uses *int 80. *Since 32-bit > environment is already supported by lx brand, we can just focus on > *syscall*emulation. > > I will start from enabling 64-bit program execution in a lx zone first. The > source files related (so other code is architecture independent?) include: > > *usr/src/uts/intel/lx_brand/lx_brand_asm.s* for system call callbacks; > ** > *usr/src/lib/brand/lx/lx_brand/i386/* > * lx_crt.s:* start entry of lx brand support lib; > * lx_handler.s* for signal handing; > * lx_runexe.s:* jumping to the ld-linux.so. > > Any suggestion? > > Regards, > > Wei Shen > _______________________________________________ > brandz-discuss mailing list > brandz-discuss at opensolaris.org >
