Re: Fails to build sys/i386/boot2 with gcc 4.9
On Mar 29, 2015, at 6:37 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 29, 2015, at 15:56, Warner Losh i...@bsdimp.com wrote: On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote: If we built a UFS1-only boot2, that would fit in the 7.5k we have left to play with. We could then build a UFS2-only boot2 that would easily fit in the like 32k limit that UFS2 has. The only reason we went to supporting both was to have something universal. Since it requires a reformat to go from UFS1 - UFS2 we wanted the transition to be as smooth as possible so you didn’t have to add boot blocks into the mix. Now the only people that use UFS1 are people with really old systems that are never going to upgrade, or people building new systems with UFS1 because they are space constrained (for whatever reasons that we’re not going to debate here: they are still real). In the past 5 years, I have worked on some embedded systems where UFS1 was chosen because of very low memory and disk space requirements. So those systems are real and out there. Just out of curiousity, what is it about newer compilers that cause the size of boot2 to increase so much? Could we do some silly things like removing/reducing the use of printf() to save some more bytes, in order to buy us more time, before having to rewrite everything? :) Removing printf isn’t going to save us. It usually compiles to 80-120 bytes. I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe some safety belts in the boot block splatter programs to prevent brickification. Since the proposal to split up the code by filesystems is on the table, would it make sense to do something similar for zfs? Thanks! zfs isn’t in boot2 by default, just ufs1 and ufs2, so I on’t understand the question. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Fails to build sys/i386/boot2 with gcc 4.9
On Mar 29, 2015, at 15:56, Warner Losh i...@bsdimp.com wrote: On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote: If we built a UFS1-only boot2, that would fit in the 7.5k we have left to play with. We could then build a UFS2-only boot2 that would easily fit in the like 32k limit that UFS2 has. The only reason we went to supporting both was to have something universal. Since it requires a reformat to go from UFS1 - UFS2 we wanted the transition to be as smooth as possible so you didn’t have to add boot blocks into the mix. Now the only people that use UFS1 are people with really old systems that are never going to upgrade, or people building new systems with UFS1 because they are space constrained (for whatever reasons that we’re not going to debate here: they are still real). In the past 5 years, I have worked on some embedded systems where UFS1 was chosen because of very low memory and disk space requirements. So those systems are real and out there. Just out of curiousity, what is it about newer compilers that cause the size of boot2 to increase so much? Could we do some silly things like removing/reducing the use of printf() to save some more bytes, in order to buy us more time, before having to rewrite everything? :) Removing printf isn’t going to save us. It usually compiles to 80-120 bytes. I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe some safety belts in the boot block splatter programs to prevent brickification. Since the proposal to split up the code by filesystems is on the table, would it make sense to do something similar for zfs? Thanks! ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Fails to build sys/i386/boot2 with gcc 4.9
I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Buildling sys/i386/boot2 failed: ... output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0 -1007 bytes available *** Error code 1 Oof, this is going to be hard to fix. For some reason, boot2 is one of those programs that keeps getting worse (i.e. larger) with *each* new compiler version, be it gcc or clang! The last few times when we imported a new clang version, we had to jump through several hoops, and attempted to shrink the code again with various cleanups. Even then, we don't have a lot of headroom. If it is now also becoming a problem with gcc 4.9, we should really start looking for a more permanent solution, e.g.: * Getting rid of the 7680 byte limit (seems to be impossible?) * Rewrite most of (or all of) boot2 in assembly We can also get rid of UFS1 support... That shrinks the code a lot. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Fails to build sys/i386/boot2 with gcc 4.9
On Mar 29, 2015, at 2:27 AM, Roman Divacky rdiva...@freebsd.org wrote: I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Buildling sys/i386/boot2 failed: ... output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0 -1007 bytes available *** Error code 1 Oof, this is going to be hard to fix. For some reason, boot2 is one of those programs that keeps getting worse (i.e. larger) with *each* new compiler version, be it gcc or clang! The last few times when we imported a new clang version, we had to jump through several hoops, and attempted to shrink the code again with various cleanups. Even then, we don't have a lot of headroom. If it is now also becoming a problem with gcc 4.9, we should really start looking for a more permanent solution, e.g.: * Getting rid of the 7680 byte limit (seems to be impossible?) * Rewrite most of (or all of) boot2 in assembly We can also get rid of UFS1 support... That shrinks the code a lot. No we can’t. And that’s kinda the useless decision to make if you look at where the 8k limit comes from. UFS1 imposes the 8k limit. UFS2 has no such limit, but there’s some issues with some old installs listing 8k as the size to fit into the disklabel reserves of the time. If we built a UFS1-only boot2, that would fit in the 7.5k we have left to play with. We could then build a UFS2-only boot2 that would easily fit in the like 32k limit that UFS2 has. The only reason we went to supporting both was to have something universal. Since it requires a reformat to go from UFS1 - UFS2 we wanted the transition to be as smooth as possible so you didn’t have to add boot blocks into the mix. Now the only people that use UFS1 are people with really old systems that are never going to upgrade, or people building new systems with UFS1 because they are space constrained (for whatever reasons that we’re not going to debate here: they are still real). All typical installs are UFS2. As such, with a bit of automation in our boot block writing, and we should be in good shape. So no, we can’t get rid of UFS1 support and have all our problems be solved. However, we likely can solve most of the issues by moving away from a single image. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
FYI: Things that I've noticed for powerpc64-xtoolchain-gcc...
You [Craig Rodrigues] seem to be checking some ??-xtoolchain-gcc things
officially. I've some user-experience notes from happening to use
powerpc64-xtoolchain-gcc in my exploration of FreeBSD. Hopefully some of it
might be of interest. It groups together information from various notices as I
was doing the explorations.
I've been exploring FreeBSD, in part using powerpc64-xtoolchain-gcc --but on a
powerpc64 11.0-CURRENT environment for the points at hand: A form of
self-hosting xtoolchain use. As stands I'm limited to powerpc64 and powerpc
contexts for FreeBSD, PowerMacs specifically. So I might over infer general
??-xtoolchain-gcc properties.
My use is not generally of the grab-source and buildworld/buildkernel from
scratch kind of context. The closest I came to that was rebuilding a gcc 4.2.1
built powerpc64 11.0-CURRENT to be a powerpc64-gcc based 11.0-current that had
libc++ in use.
After that I've updated (svnlite update -r??) and rebuilt a newer
11.0-CURRENT.
I'm not sure if the continuous integration or other ??-xtoolchain-gcc testing
checks on rebuild-for-update kind of context or not. One of the things of note
for me is specific to that kind of context where headers and libraries
temporarily have both old and new vintages around and the right ones need to be
used in specific stages. Other aspects of my use might also go outside the
range of your activity as well.
The primary things that I've run into include:
A) Rebuilds from updated sources were picking up old headers (from, for
example, /usr/include) and old libraries, not just for legacy/ where such makes
sense.
B) I had a specific problem originally with atf-c++ finding the C++ standard
library headers. I added a specific -I for what was
${WORLDTMP}/usr/include/c++/v1 in order for it to find the files. I also put in
a matching -L for /usr/obj/usr/src/lib/libc++ .
C) powerpc64-gcc automatically looks in /usr/local/include for header files
(like most such ports) and this can pick up the wrong file(s). I ended up using
the manual policy of renaming /usr/local/include/iconv.h during
buildworld/buildkernel so that it would not be found and used where the build
should have found a file with different content from my /usr/src/... area (or
its WORLDTMP copy).
D) I've been limited to WITHOUT_BOOT= WITHOUT_LIB32= by being unable to get the
32-bit environment activity to work: CROSS_TOOLCHAIN=powerpc64-gcc use did not
allow the -melf32ppc_fbsd . Does targeting i386 for BOOT and LIB32 from amd64
have a similar problem with -melf_i386_fbsd ?
E) I've been limited to WITHOUT_GCC_BOOTSTRAP= by XCC being a full path making
the build environment ignore WITH_GCC_BOOTSTRAP= . Similarly WITH_GCC= does not
actually cause gcc 4.2.1 to be built. (I wanted WITHOUT_GNUCXX= in order to try
libc++ only. So I've not tried WITH_GNUCXX= .)
F) I've been limited to WITHOUT_CLANG_BOOTSTRAP= WITHOUT_CLANG= WITHOUT_LLDB=
by various issues when clang related builds are involved. I'll not go into
details.
G) Last I tried it powerpc64-xtoolchain-gcc does not correctly install itself
automatically when one attempts to install it in a powerpc64-host context. (It
installs fine on a powerpc (non-64) host context.) This may be associated with
the same points that make the distinction between
/usr/obj/powerpc.powerpc64/usr/src/ (on/in powerpc (non-64)) and
/usr/obj/usr/src/ (on/in powerpc64) as a default path: in part the errors were
empty file name prefixes vs. filled-in prefixes.
H) After the gcc 4.2.1 - 4.9.1 bootstrap I had to rebuild powerpc64-gcc in
order to get the -pg compiles to always work: without that at least one
required example of such a compile crashed the compiler every time it was
tried. All -pg compiles worked fine after the rebuild. (I used gcc5 to rebuild
4.9.1 because of (G) ending up involved otherwise.) Before, when still booted
from the gcc-4.2.1-based world, the original gcc 4.9.1 compiler did not crash
for -pg compiles.
I) Trying to use powerpc64-xtoolchain-gcc from a powerpc (non-64) host does not
work. One aspect is tool chain related: C/C++/assembler usage need to be told
to be 64-bit such that, for example, __powerpc64__ ends up defined for
pre-processor use. That is not happening and incorrect processor generated
files result. For example the assembler reports syntax errors from lack of
definitions related to TOC use for powerpc64.
There are some work arounds involved for things very powerpc64/powerpc context
specific, such as some Makefile*'s forcing use of CC:=gcc . I've not noted such
things above: The above targets what I'd guess might be more general issues.
I've also not noted when 11.0-CURRENT has required a few files to have specific
versions picked out that did not match the snapshot I was generally using at
the time.
My current context for this is:
# freebsd-version -ku; uname -apKU
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0
Re: Fails to build sys/i386/boot2 with gcc 4.9
On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote: If we built a UFS1-only boot2, that would fit in the 7.5k we have left to play with. We could then build a UFS2-only boot2 that would easily fit in the like 32k limit that UFS2 has. The only reason we went to supporting both was to have something universal. Since it requires a reformat to go from UFS1 - UFS2 we wanted the transition to be as smooth as possible so you didn't have to add boot blocks into the mix. Now the only people that use UFS1 are people with really old systems that are never going to upgrade, or people building new systems with UFS1 because they are space constrained (for whatever reasons that we're not going to debate here: they are still real). In the past 5 years, I have worked on some embedded systems where UFS1 was chosen because of very low memory and disk space requirements. So those systems are real and out there. Just out of curiousity, what is it about newer compilers that cause the size of boot2 to increase so much? Could we do some silly things like removing/reducing the use of printf() to save some more bytes, in order to buy us more time, before having to rewrite everything? :) -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Failed to build usr.bin/clang/clang with gcc 4.9
On 29 Mar 2015, at 22:39, Craig Rodrigues rodr...@freebsd.org wrote: When building with gcc 4.9, I am getting unresolved symbols at link time when building usr.bin/clang/clang. Here is one error message: /usr/obj/opt2/branches/head/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclang codegen.a(ModuleBuilder.o): In function `(anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext)': ModuleBuilder.cpp:(.text+0x113): undefined reference to `clang::CodeGen::CodeGenModule::clear()' There are many more errors like that in my full build log here: https://people.freebsd.org/~rodrigc/gcc/buildworld.2015_03_29.log.txt For some reason, many of your libraries aren't being built: stage 4.2: building libraries ... === lib/libwrap (all) === lib/libxo (all) === lib/liby (all) === lib/atf (all) === lib/atf/libatf-c (all) === lib/atf/libatf-c++ (all) === lib/clang (all) === lib/clang/libclanganalysis (all) === lib/clang/libclangarcmigrate (all) === lib/clang/libclangast (all) === lib/clang/libclangbasic (all) === lib/clang/libclangcodegen (all) === lib/clang/libclangdriver (all) === lib/clang/libclangedit (all) === lib/clang/libclangfrontend (all) And none of these prints any compilation command lines? Are you running with make -s, by any chance? If so, try removing it so we can see how the various source files are being compiled. Also, do any of the libclang*.a files under /usr/obj look sane? E.g., do they contain any object files, and if so, why are the symbols you showed missing? -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Failed to build usr.bin/clang/clang with gcc 4.9
Hi, When building with gcc 4.9, I am getting unresolved symbols at link time when building usr.bin/clang/clang. Here is one error message: /usr/obj/opt2/branches/head/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclang codegen.a(ModuleBuilder.o): In function `(anonymous namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext)': ModuleBuilder.cpp:(.text+0x113): undefined reference to `clang::CodeGen::CodeGenModule::clear()' There are many more errors like that in my full build log here: https://people.freebsd.org/~rodrigc/gcc/buildworld.2015_03_29.log.txt Any ideas? -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Fails to build sys/i386/boot2 with gcc 4.9
On Mar 29, 2015, at 13:29, Craig Rodrigues rodr...@freebsd.org wrote: Just out of curiousity, what is it about newer compilers that cause the size of boot2 to increase so much? Code generation is different, especially with regards to optimisations. Longer code might be faster because the compiler decided to inline a few functions. Unfortunately, I never saw any difference between -Os and -O2 in all of my tests (boot2 and other code). -- Rui Paulo ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org
Re: Fails to build sys/i386/boot2 with gcc 4.9
On Mar 29, 2015, at 2:29 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh i...@bsdimp.com wrote: If we built a UFS1-only boot2, that would fit in the 7.5k we have left to play with. We could then build a UFS2-only boot2 that would easily fit in the like 32k limit that UFS2 has. The only reason we went to supporting both was to have something universal. Since it requires a reformat to go from UFS1 - UFS2 we wanted the transition to be as smooth as possible so you didn’t have to add boot blocks into the mix. Now the only people that use UFS1 are people with really old systems that are never going to upgrade, or people building new systems with UFS1 because they are space constrained (for whatever reasons that we’re not going to debate here: they are still real). In the past 5 years, I have worked on some embedded systems where UFS1 was chosen because of very low memory and disk space requirements. So those systems are real and out there. Just out of curiousity, what is it about newer compilers that cause the size of boot2 to increase so much? Could we do some silly things like removing/reducing the use of printf() to save some more bytes, in order to buy us more time, before having to rewrite everything? :) Removing printf isn’t going to save us. It usually compiles to 80-120 bytes. I think the only sane way forward is boot2.ufs1 an boot2.ufs2 plus maybe some safety belts in the boot block splatter programs to prevent brickification. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
