Date: Sun, 14 Sep 2014 09:40:21 -0400 From: Eric McCorkle <eric@metricspace.net> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Resuming old EFI project Message-ID: <54159AC5.1010800@metricspace.net>
next in thread | raw e-mail | index | archive | help
Hello everyone, About two years ago, I was working on a project to try and finish the EFI support for AMD64. Unfortunately, I had to abandon the project due to family illness and a job search. At this point, I'm in a position to pick that project back up as a side project (I also have better hardware now ;) It seems everything in sys/boot/amd64/efi is pretty much unchanged. One thing that's changed things quite a bit, though, is the switch to clang. When I was working on it before, there was a custom linker script that got used to produce loader as a PE binary (EFI uses the PE format and win32 ABI). However, that script seemed to produce bad offsets when using clang. On the other hand, clang can cross-compile to the win32 ABI (by giving it -target x86_64-unknown-win32). This does have some additional advantages; win32 has slightly different conventions, and I remember reading about an issue someone was having because of a stack alignment issue when they were using a linker script solution. So the thing to do might be to cross-compile loader and its dependencies (stand, ficl, if I recall). The issue here is that you'd potentially be producing two sets of libraries: one with the standard ABI and one with the win32 ABI. Worth noting: there's supposedly a way to get clang to produce "object" files that are actually LLVM bitcode; that could potentially avoid generating two sets of object files. I welcome any suggestions or comments.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54159AC5.1010800>