Date: Mon, 24 Jun 2013 11:17:55 -0700 From: Jack Wilborn <jkwilborn@gmail.com> To: Paul Mather <pmather@vt.edu> Cc: "Jordan K. Hubbard" <jkh@turbofuzz.com>, freebsd-arm@freebsd.org Subject: Re: Raspberry pi not ready to self-host yet? Message-ID: <CAKmExv2XP4%2BFys%2BBYNAO=jXmTBecQgMwrWz6RJ2Ahy0codR0Vg@mail.gmail.com> In-Reply-To: <9312A37D-E708-4369-9702-53BB9B6636C8@vt.edu> References: <800732D1-B06A-40AE-AE69-F6170662B2AA@turbofuzz.com> <3B1B1A39-13AF-4718-A9D6-757D6FEFC27F@bsdimp.com> <9312A37D-E708-4369-9702-53BB9B6636C8@vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan, I don't know if I'm any help or not, as I do not build with this environment, but I do work with compilers/linkers and error messages and can say what it's complaint is, if that helps? I have looked at this from someone else and understand the compile works on another architecture, if this is correct then the syntax of the source should be correct. I am not a C++ person, but the source looks ok from what I've seen of the basic_string.tcc. However I will make another statement that this code may not be 'in the source' being built on another machine. What I'm saying is that this code may be redundant or not even required and the preprocessors may eliminate it from the source. If this is failing with all architectures then the parts of the previous statement is invalid. I am always suspicious about variable or such that are link special defines such as 'std' as in stdin or stdout... There may be some kind of meaning to them. If on the other hand it is there and it being compiled the source is syntactically correct. This error is telling you that the source pointer is pointing at a ";", or the end of a statement. Next it's trying to evaluate the 'std' variable or item within the statement. Next, it loses it and the program 'abends' in mainframe terminology (abnormal ending). It goes somewhere that causes it to go out of bounds for the compiler, such as another user or system memory. The program has had a fatal process and this is the only thing it can do, is complain and halt. The next errors are linker errors it cannot find the designated symbol(s) the first of which is "_atomic_load_4". Notice that I have used only one underscore as the linker, looking for an external symbol will perpend an underscore, so the function is probably that name less one underscore. A simple reason for these errors are that (1) they exist within the abended source and were never compiled or the compilation ended and the linker continued. With this type of error, the script should have ended without the linker invocation, as when the compile fails you know the link will also fail. I hope this assists to some extent. If I am not of use, please let me know and I will keep quiet... I still would think that the linker should have never been invoked, as you know it will fail. Jack On Mon, Jun 24, 2013 at 8:18 AM, Paul Mather <pmather@vt.edu> wrote: > On Jun 24, 2013, at 11:01 AM, Warner Losh <imp@bsdimp.com> wrote: > > > > > On Jun 24, 2013, at 8:55 AM, Jordan K. Hubbard wrote: > > > >> Hi folks, > >> > >> I followed the instructions in the repo at > https://github.com/daveish/freebsd-arm-tools.git and was able to create a > bootable SD image for my 512Mb PI in no time with very little hassle - nice > job there! > >> > >> What I can't seem to manage, however, is to self-host after that. I > see someone has already filed > http://www.freebsd.org/cgi/query-pr.cgi?pr=178495 covering the failure > during buildworld, You see the same compilation error in basic_string.tcc > in various ports, like apr: > >> > >> 0. Program arguments: /usr/bin/c++ -cc1 -triple > armv6-unknown-freebsd10.0 -S -disable-free -main-file-name cxx_db.cpp > -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -mconstructor-aliases > -target-abi apcs-gnu -target-cpu arm1136jf-s -msoft-float -mfloat-abi soft > -target-feature +soft-float -target-feature +soft-float-abi -target-feature > -neon -coverage-file /tmp/cxx_db-5qpGsC.s -resource-dir > /usr/bin/../lib/clang/3.3 -D _THREAD_SAFE -D PIC -I . -I ./../dist/.. -O2 > -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir > /a/ports/databases/db42/work/db-4.2.52/build_unix -ferror-limit 19 > -fmessage-length 144 -mstackrealign -fno-signed-char -fobjc-runtime=gnustep > -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions > -fsjlj-exceptions -fdiagnostics-show-option -fcolor-diagnostics > -backend-option -vectorize-loops -o /tmp/cxx_db-5qpGsC.s -x c++ > ./../dist/../cxx/cxx_db.cpp > >> 1. /usr/include/c++/4.2/bits/basic_string.tcc:978:43: current parser > token ';' > >> 2. /usr/include/c++/4.2/bits/basic_string.tcc:48:1 > <Spelling=/usr/include/c++/4.2/bits/c++config.h:76:38>: parsing namespace > 'std' > >> c++: error: unable to execute command: Segmentation fault (core dumped) > >> c++: error: clang frontend command failed due to signal (use -v to see > invocation) > > > > do you have enough swap? Clang is a memory pig dog... > > > >> In the kernel, there seems to be something weird with the atomics > because linking always fails: > >> > >> kern_event.o: In function `filt_timerattach': > >> /a/src/sys/kern/kern_event.c:555: undefined reference to > `__atomic_load_4' > >> /a/src/sys/kern/kern_event.c:559: undefined reference to > `__atomic_compare_exchange_4' > >> kern_event.o: In function `filt_timerdetach': > >> /a/src/sys/kern/kern_event.c:584: undefined reference to > `__atomic_fetch_sub_4' > > > > Now that's odd. I'll look into that... > > > >> I do appreciate that it's a heck of a lot easier to cross-compile for > these things, and great work getting things to this point, but self-hosting > is still one of the magical milestones you always hope an embedded target > will get to someday, assuming it actually has enough grunt to do so (and I > think the PI does). :) > > > > I've self-hosted FreeBSD on an Atmel AT91SAM9620 recently (arm v5 > board)... Seems odd that cross compile and native built give different > results. Will look into it. Btw, whats uname -p say for you? > > I have only ever managed successfully to self-host on the Raspberry Pi > when using GCC, not Clang, to build as the default compiler. I think until > PR arm/178495 is resolved (which appears to rely on the LLVM folks fixing > it), it won't be possible to buildworld using Clang. > > Maybe the default compiler should be flipped back to GCC on arm, as it > appears Clang is not yet suitable for prime time there? > > Whatever alignment bug is affecting clang on arm doesn't appear to affect > clang on amd64, which is why I can happily cross-build a clang-based arm > image for my Raspberry Pi using crochet. > > Cheers, > > Paul. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKmExv2XP4%2BFys%2BBYNAO=jXmTBecQgMwrWz6RJ2Ahy0codR0Vg>