Compiling Xen on FreeBSD using clang ...
mgrooms at shrew.net
Sun Oct 19 22:29:33 UTC 2014
On 10/19/2014 2:27 PM, Dimitry Andric wrote:
> On 19 Oct 2014, at 18:34, Matthew Grooms <mgrooms at shrew.net> wrote:
>> As most of you are probably aware, Roger at Citrix R&D has been doing some incredible work to bring PVH domU/dom0 support to FreeBSD. There has also been an effort by other Xen developers to get the software to compile using clang. While most of these attempts appear to be on Linux platforms targeting arm processors, the FreeBSD version of binutils is quite a bit older. Clang still can't parse all of the assembly that Xen requires, so unfortunately the -no-integrated-as option has to be used in several cases.
> What kind of assembly is that? And are you using clang 3.4.1 from base?
There wasn't much of Xen proper that had issues compiling the assembly.
Most of the headache came when compiling seabios which is wrapped up in
the Xen source code. One problem was the .code16 sections as mentioned
by Marcin Cieslak later in this email thread. Maybe related to this?
I tried passing the "-m16" flag to clang 3.4.1, but it complained about
not being a recognized option ( or I wasn't using it properly ). Maybe
support for this was first included in the 3.4.2 or the 3.5 release.
>> Which brings me to my question, is there a way to ask clang to use the ports version of binutils when -no-integrated-as is passed to clang? The version of 'as' in base fails to compile such as ...
>> /tmp/misc-bf1339.s: Assembler messages:
>> /tmp/misc-bf1339.s:375: Error: unknown pseudo-op: `.cfi_sections'
> Yes, binutils in base is forever stuck at version 2.17.50, which is
> ancient by by now.
>> If /usr/local/bin/as is symlinked to /usr/bin/as, the compile completes but I assume there is a better way to tell clang where the external as binary is when -no-integrated-as is invoked. I've googled a bunch but came up empty handed so far. I thought it would be worth asking here in case someone has already run across this problem and had more insight.
> Yes, just pass -B/usr/local/bin on the command line. Note that this
> will make it search for *all* external tools in /usr/local/bin, e.g.
> ld will also be run from there. For example:
Thanks for the feedback. I'll try this out. My goal was to get a set of
patches that could be used to pull Xen into the ports tree. With that in
mind I was trying to rely on the system compiler as much as possible. If
an LLVM 3.5 import is imminent, then it may solve all of the issues, at
least for CURRENT ( the only dom0 relevant branch ).
> $ clang -v -no-integrated-as -B/usr/local/bin hello-world.c -o hello-world
> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
> Target: i386-unknown-freebsd11.0
> Thread model: posix
> Selected GCC installation:
> "/usr/bin/clang" -cc1 -triple i386-unknown-freebsd11.0 -S -disable-free -main-file-name hello-world.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -v -resource-dir /usr/bin/../lib/clang/3.4.1 -fno-dwarf-directory-asm -fdebug-compilation-dir /share/dim/src/misc -ferror-limit 19 -fmessage-length 297 -mstackrealign -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /home/dim/tmp/hello-world-410124.s -x c hello-world.c
> clang -cc1 version 3.4.1 based upon LLVM 3.4.1 default target i386-unknown-freebsd11.0
> ignoring nonexistent directory "/usr/bin/../lib/clang/3.4.1/include"
> #include "..." search starts here:
> #include <...> search starts here:
> End of search list.
> "/usr/local/bin/as" --32 -o /home/dim/tmp/hello-world-288694.o /home/dim/tmp/hello-world-410124.s
> "/usr/local/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o hello-world /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib /home/dim/tmp/hello-world-288694.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
More information about the freebsd-current