Date: Tue, 17 Aug 2010 09:03:47 +1200 From: Andrew Turner <andrew@fubar.geek.nz> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD EABI ARM & Network boot image howto? Message-ID: <20100817090347.6fdb6665@fubar.geek.nz> In-Reply-To: <20100816.102815.72112000494883288.imp@bsdimp.com> References: <1281907405.27697.19.camel@xeon.thinmesh.com> <20100815.153437.722022410199781366.imp@bsdimp.com> <20100816221321.180cf466@fubar.geek.nz> <20100816.102815.72112000494883288.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Aug 2010 10:28:15 -0600 (MDT) "M. Warner Losh" <imp@bsdimp.com> wrote: > In message: <20100816221321.180cf466@fubar.geek.nz> > Andrew Turner <andrew@fubar.geek.nz> writes: > : On Sun, 15 Aug 2010 15:34:37 -0600 (MDT) > : "M. Warner Losh" <imp@bsdimp.com> wrote: > : > There was talk about NetBSD making this move too, but I don't know > : > what became of it. > : I haven't looked at if NetBSD supports it or not. My work was > mostly a : weekend hacking to prove it is possible. > : > : > I'm guessing it won't be a huge deal to make this work, just a > bunch : > of elbow grease in the syscalls... > : > : The main problem is getting a list of syscalls that need to be > changed. : I found I could boot to single user mode by only changing > stat and : fstat. I'm currently in the process of converting my hack > to using the : same method to provide 32 bit and Linux compatability > support. > > Sadly, you're going to have to step through each one and see if it > changes. On MIPS, we had to do similar things for n32/n64 support > since some syscalls it mattered for. But n32 support is by far the > weirdest ABI beast in the jungle. I have managed to find some of the structs that need a compat version. I'm also looking at what syscalls are reimplemented for freebsd32. > So we're going to have multiple image activators on ARM? Is that the > plan? Or is there some other way that you had in mind... I haven't looked in to this yet. > : We also need to decide if we follow what Linux has done where it > : changed it's syscall ABI when it moved to the EABI. They changed > from : reading the instruction from memory to get the syscall number > to : storing it in r7. The idea is to reduce the cost of the data > cache miss : as the page will be in the instruction cache. I hacked > up some code to : do the same but haven't had a chance to properly > benchmark the change : yet. > > I think this is a good change as well. The compat layer can easily > cope. Some of the code in trap.c needs to be updated for this first. > Are there other ABI issues we wish to fix at the same time? I don't know of any other ABI issues. If anyone else does I'm happy to look into them. > And will > this also help solve the funky alignment issues we've had with ARM > elsewhere in the kernel causing problems either in structure sizes or > unaligned accesses? With the EABI the alignment of structs is determined by the contents where the current ABI they are aligned to 4 bytes. The packing is different with 64 bit components. They will start on a 64 bit boundary. I've already found some issues e.g. struct stat. I haven't looked at e.g. how broken the network stack is (if at all). > Are there other implications we need to worry about? Are you going to > try to support both the current ABI and EABI in the current source > tree? I was going to support both for userland only when the kernel is built with EABI. If the kernel is built with the current ABI userland needs to also be built with it. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100817090347.6fdb6665>