On Sun, Mar 25, 2012 at 3:19 PM, Ivan Sichmann Freitas < ivansichfrei...@gmail.com> wrote:
> On Thu, Mar 22, 2012 at 12:40:07AM -0300, Ivan Sichmann Freitas wrote: > > Hi, > > > > I'm a computer engineering student at Unicamp (brazilian university), > > interested in compilers and computer architecture (and most low level > > stuff), and the idea of implementing the ABI for running 32 bit > > applications on a 64 bit kernel seems interesting and challenging. > > > > I have moderated knowledge of C, OS principles and Linux systems, some > > experience with FreeBSD, I've already cloned dragonfly's git repository > > and I'm studying the code to come with a planned roadmap of what would > > be my work in gsoc. You can find me with the username ISF in github and > > IRC networks (efnet, freenode and oftc). > > So, as far as I understood the idea and dragonfly's code: > - since the current code was created to be of only one architecture, > I would need to create a set of *_32 syscalls (will they maintain > the same numeric value in syscalls.master in relation of its 64 > bits counterparts?). > - it's not clear to me how I will implement the control bits to > indicate 32 bit execution. > - I'm thinking in a way to implement this without breaking the > current 64 bit abi for existing applications, any thoughts on > that? > > As a draft of my planned roadmap: > - completely understand the syscalls' handling in the kernel > - analyze the difference of 32 and 64 elf formats and how it affects > the loader > - plan the implementation (try to avoid abi breakage and pitfalls) > - do it > > (not sure how much time for each step, but the 2 firsts should be quick) > > I would appreciate any feedback on this. > > -- > Ivan Sichmann Freitas > GNU/Linux user #509059 > You basically have it. Basically I think what it boils down to is a 32-bit syscall layer that maps/translates/casts/converts as the case may be the 32-bit arguments to 64-bit arguments, calls the native 64-bit version of the system call and then translates the return value as-necessary on the way back. (This is probably mostly just a lot of grunt work, once the framework is in place). We have a mechanism for executing a binary with a specific kernel system call vector, we use this to support Linux binaries, for example. You just need to create a 32-bit vector, or re-use the main vector built with 32-bit types, or similar for the 64-bit kernel and make sure that it is what gets used when a 32-bit binary is executed. FreeBSD has done this and the whole approach should be extremely similar, it would be worth looking at what they have done and it is likely worth simply copying their approach. I will note that it is possible this project exceeds the scope of GSoC, but that as long as it is done well even as little as 30 or 40% syscall coverage is still probably quite useful and may be capable of running many simple binaries. As a contingency, you should probably plan to create some documentation about the translation layer so that if you don't achieve complete system call coverage or if people add system calls in the future it is easy to identify how system calls are to be added to the translation -- assuming it isn't all automatic. Sam
