On 10/19/2014 2:27 PM, Dimitry Andric wrote:
On 19 Oct 2014, at 18:34, Matthew Grooms <mgro...@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 
clang -cc1 version 3.4.1 based upon LLVM 3.4.1 default target 
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 
  "/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


Thanks again,


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to