Raspberry pi not ready to self-host yet?

Mon Jun 24 18:17:55 UTC 2013

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 at vt.edu> wrote:

> On Jun 24, 2013, at 11:01 AM, Warner Losh <imp at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>