[Differential] [Commented On] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage
dim added inline comments.
BRANCH
/head
INLINE COMMENTS
Makefile.inc1:416 I just looked for the LD=${LD} assignments, and replaced
them all. Maybe, for consistency, we should add OBJCOPY=${XOBJCOPY} for the
powerpc case too, but I'm not sure if it's used at all in the powerpc build...
REVISION DETAIL
https://reviews.freebsd.org/D2187
To: dim, rodrigc, bapt, emaste, imp
Cc: emaste, imp, freebsd-toolchain
___
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
[Differential] [Closed] D1722: Add -s option to config
rodrigc closed this revision. rodrigc added a comment. Committed under rS277904 REVISION DETAIL https://reviews.freebsd.org/D1722 To: rodrigc, brooks, imp Cc: freebsd-toolchain ___ 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: Kernel compilation failures with gcc 4.9
On Tue, Mar 31, 2015 at 10:10 PM, John-Mark Gurney j...@funkthat.com wrote: This is an issue w/ gcc 4.9's headers... It is including stdlib.h, via mm_malloc.h which is conflicting w/ sys/malloc.h's version of free.. kan wrapped the include of mm_malloc.h in an #if __STDC_HOSTED__ which is why gcc 4.2 doesn't have the issue per my request a couple years ago: https://svnweb.freebsd.org/changeset/base/r242182 A similar fix needs to be applied here... Interesting, so r242182 does this inside the gcc header file itself: --- head/contrib/gcc/config/i386/xmmintrin.h 2011/03/14 13:31:34 219639 +++ head/contrib/gcc/config/i386/xmmintrin.h 2012/10/27 17:39:36 242182 @@ -39,7 +39,9 @@ #include mmintrin.h /* Get _mm_malloc () and _mm_free (). */ +#if __STDC_HOSTED__ #include mm_malloc.h +#endif We would need to apply the same patch to the gcc header file in gcc 4.9. I'm not sure if that will be allowed, since the direction we are going in is to support gcc as an external toolchain, unless we can push that change upstream to gcc. I'll let the toolchain@ team decide that one. The alternative is to patch the aesni header files. This patch is a bit gross, but I was able to compile an entire GENERIC kernel (including aesni) with gcc 4.9: Index: aesni/aesencdec.h === --- aesni/aesencdec.h(revision 280912) +++ aesni/aesencdec.h(working copy) @@ -27,6 +27,11 @@ * */ +#ifdef _KERNEL +/* Suppress inclusion of gcc's mm_malloc.h header */ +#define _MM_MALLOC_H_INCLUDED 1 +#endif + #include wmmintrin.h static inline void Index: aesni/aesni_ghash.c === --- aesni/aesni_ghash.c(revision 280912) +++ aesni/aesni_ghash.c(working copy) @@ -71,6 +71,11 @@ #include stdint.h #endif +#ifdef _KERNEL +/* Suppress inclusion of gcc's mm_malloc.h header */ +#define _MM_MALLOC_H_INCLUDED 1 +#endif + #include wmmintrin.h #include emmintrin.h #include smmintrin.h Index: aesni/aesni_wrap.c === --- aesni/aesni_wrap.c(revision 280912) +++ aesni/aesni_wrap.c(working copy) @@ -45,6 +45,11 @@ #include opencrypto/gmac.h #include aesencdec.h +#ifdef _KERNEL +/* Suppress inclusion of gcc's mm_malloc.h header */ +#define _MM_MALLOC_H_INCLUDED 1 +#endif + #include smmintrin.h MALLOC_DECLARE(M_AESNI); What's the best way to move forward on this? -- 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: Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64)
[I've omitted history going in a different direction than this note.] On 2015-Apr-1, at 02:49 PM, Warner Losh imp at bsdimp.com wrote: On Apr 1, 2015, at 4:37 PM, Mark Millard mar...@dsl-only.net wrote: From a powerpc (non-64) 11.0-CURRENT boot is the following supposed to work by producing a powerpc64 appropriate result (no CROSS_TOOLCHAIN for this question)? make buildworld buildkernel KERNCONF=GENERIC64 TARGET=powerpc TARGET_ARCH=powerpc64 This should work, modulo broken compilers. The standard v4.2.1 /usr/bin/gcc in a powerpc context (non-64) for that make command would produce files for TARGET_ARCH=powerpc unless the command lines specified otherwise. Ah, so it is a ‘cross build’ situation... Notably the build environment is picking powerpc64 specific paths when appropriate, such as: lib/csu/powerpc64/Makefile so that specific Makefile is not likely to be used when powerpc64 handling is inappropriate, even executed from from a powerpc (non-64) context. A different path (and so a distinct Makefile) would be used for KERNCONF=GENERIC TARGET_ARCH=powerpc . After some experimentation I think that I've learned that I'd not guessed the existence of a required step to enable make buildkernel KERNCONF=GENERIC64 TARGET=powerpc TARGET_ARCH=powerpc64 from powerpc: one first must do a... make kernel-toolchain KERNCONF=GENERIC64 TARGET=powerpc TARGET_ARCH=powerpc64 before trying buildkernel. Similarly if buildworld is going to be done then make toolchain KERNCONF=GENERIC64 TARGET=powerpc TARGET_ARCH=powerpc64 should be done first. These put in place a tailored gcc 4.2.1 build into the appropriate part of the /usr/obj/... tree and once it exists the path used during make picks up the sub-tree-specific gcc 4.2.1. The defaults for this tree-specific gcc do not require command line options to specify the default context for the special TARGET_ARCH. Similarly for building for powerpc from powerpc64. === Mark Millard markmi at dsl-only.net ___ 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: Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64)
On Apr 1, 2015, at 4:37 PM, Mark Millard mar...@dsl-only.net wrote:
On 2015-Apr-1, at 02:49 PM, Warner Losh imp at bsdimp.com wrote:
On Apr 1, 2015, at 2:44 PM, Mark Millard mar...@dsl-only.net wrote:
Attempting to use CROSS_TOOLCHAIN=powerpc64-gcc on powerpc (non-64)
11.0-CURRENT with TARGET_ARCH=powerpc64 gets:
--- crti.o ---
gcc -O2 -pipe -I/usr/srcC/lib/csu/powerpc64/../common
-I/usr/srcC/lib/csu/powerpc64/../../libc/include -mlongcall -std=gnu99
-Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign-c
/usr/srcC/lib/csu/powerpc64/crti.S
...
/usr/srcC/lib/csu/powerpc64/crti.S: Assembler messages:
/usr/srcC/lib/csu/powerpc64/crti.S:35: Error: junk at end of line, first
unrecognized character is `@'
/usr/srcC/lib/csu/powerpc64/crti.S:51: Error: junk at end of line, first
unrecognized character is `@'
*** [crti.o] Error code 1
Read below only for analysis.
First I'll deal with the error messages. Then I'll deal with the gcc.
The lines of crti.S in question are:
.quad .L._init,.TOC.@tocbase,0
...
.quad .L._fini,.TOC.@tocbase,0
The error messages are because __powerpc64__ is not defined when
machine/asm.h is included so the wrong definition is used for _ENTRY(…):
The gcc port needs to be fixed, with changes fed upstream.
The head/lib/csu/powerpc64/Makefile generated gcc as the command (see
above). That in turn ended up as using: /usr/bin/gcc , which is the FreeBSD
4.2.1 system gcc.
So no port was involved. That may be the (or a) problem: ${XCC} was not being
used.
That’s an interesting hole. It should be.
#ifdef __powerpc64__
...
#define _ENTRY(name) \
.section .text; \
.p2align 2; \
.globl name; \
.section .opd,aw; \
.p2align 3; \
name: \
.quad DOT_LABEL(name),.TOC.@tocbase,0; \
.previous; \
.p2align 4; \
TYPE_ENTRY(name) \
DOT_LABEL(name):
...
#else /* !__powerpc64__ */
#define _ENTRY(name) \
.text; \
.p2align 4; \
.globl name; \
.type name,@function; \
name:
#define _END(name)
#endif /* __powerpc64__ */
The (powerpc64 specific) Makefile may need to force a 64-bit usage (-m64
?), presuming that such is supported from the 32 bit environment.
Generally, we’ve not added those kinds of flags to the command line. There’s
many subtle issues in the tree trying to do that…
Warner
From a powerpc (non-64) 11.0-CURRENT boot is the following supposed to work
by producing a powerpc64 appropriate result (no CROSS_TOOLCHAIN for this
question)?
make buildworld buildkernel KERNCONF=GENERIC64 TARGET=powerpc
TARGET_ARCH=powerpc64
This should work, modulo broken compilers.
The standard v4.2.1 /usr/bin/gcc in a powerpc context (non-64) for that make
command would produce files for TARGET_ARCH=powerpc unless the command lines
specified otherwise.
Ah, so it is a ‘cross build’ situation...
Notably the build environment is picking powerpc64 specific paths when
appropriate, such as:
lib/csu/powerpc64/Makefile
so that specific Makefile is not likely to be used when powerpc64 handling is
inappropriate, even executed from from a powerpc (non-64) context. A
different path (and so a distinct Makefile) would be used for
KERNCONF=GENERIC TARGET_ARCH=powerpc .
The hack in that Makefile likely needs to be revisited.
Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
[Differential] [Updated, 38 lines] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage
dim updated this revision to Diff 4577. dim added a comment. This revision now requires review to proceed. Add XOBJCOPY for powerpc too. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D2187?vs=4554id=4577 BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D2187 AFFECTED FILES Makefile.inc1 lib/csu/i386-elf/Makefile sys/boot/i386/boot2/Makefile sys/boot/i386/gptboot/Makefile sys/boot/i386/gptzfsboot/Makefile sys/boot/i386/zfsboot/Makefile sys/boot/mips/beri/boot2/Makefile sys/boot/pc98/boot0.5/Makefile sys/boot/pc98/boot0/Makefile sys/boot/pc98/boot2/Makefile To: dim, rodrigc, imp, emaste, bapt Cc: emaste, imp, freebsd-toolchain ___ 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
[Differential] [Accepted] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage
emaste accepted this revision. emaste added a comment. This revision is now accepted and ready to land. LGTM BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D2187 To: dim, rodrigc, imp, bapt, emaste Cc: emaste, imp, freebsd-toolchain ___ 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
[Differential] [Commented On] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage
dim added inline comments. BRANCH /head INLINE COMMENTS Makefile.inc1:427 Btw, I'm not sure about AS here, since it might not even be used in the 32 bit stage, and also I'm not sure of the syntax. Is it -a32? REVISION DETAIL https://reviews.freebsd.org/D2187 To: dim, rodrigc, imp, bapt, emaste Cc: emaste, imp, freebsd-toolchain ___ 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: profile_rt from llvm folks?
On 1 April 2015 at 16:35, Dimitry Andric d...@freebsd.org wrote: On 01 Apr 2015, at 02:03, NGie Cooper yaneurab...@gmail.com wrote: Hi all, We've recently integrated a version of profile_rt from the llvm folks internally to replace gcov for code coverage. I was wondering if there was a plan to replace the copy of gcov in FreeBSD with the same (either in the base system, ports, or both). I personally have no plans to do so, but the build of libprofile_rt.a was added in r276857, at least. Yes, as of that change one can compile with --coverage, and .gcda and .gcno files will be produced via the functionality in libprofile_rt.a. gcov(1) is able to use them, but when I tried llvm-cov it didn't work correctly; in any case, llvm-cov is now on the roadmap for our toolchain. -Ed ___ 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: Kernel compilation failures with gcc 4.9
Craig Rodrigues wrote this message on Wed, Apr 01, 2015 at 07:59 -0700: On Tue, Mar 31, 2015 at 10:10 PM, John-Mark Gurney j...@funkthat.com wrote: This is an issue w/ gcc 4.9's headers... It is including stdlib.h, via mm_malloc.h which is conflicting w/ sys/malloc.h's version of free.. kan wrapped the include of mm_malloc.h in an #if __STDC_HOSTED__ which is why gcc 4.2 doesn't have the issue per my request a couple years ago: https://svnweb.freebsd.org/changeset/base/r242182 A similar fix needs to be applied here... Interesting, so r242182 does this inside the gcc header file itself: --- head/contrib/gcc/config/i386/xmmintrin.h 2011/03/14 13:31:34 219639 +++ head/contrib/gcc/config/i386/xmmintrin.h 2012/10/27 17:39:36 242182 @@ -39,7 +39,9 @@ #include mmintrin.h /* Get _mm_malloc () and _mm_free (). */ +#if __STDC_HOSTED__ #include mm_malloc.h +#endif We would need to apply the same patch to the gcc header file in gcc 4.9. I'm not sure if that will be allowed, since the direction we are going in is to support gcc as an external toolchain, unless we can push that change upstream to gcc. I'll let the toolchain@ team decide that one. The alternative is to patch the aesni header files. This patch is a bit gross, but I was able to compile an entire GENERIC kernel (including aesni) with gcc 4.9: Yes, I did think of that... If we do this... We need to make sure to include a comment about this hack being for GCC, and/or we should probably make it dependant on GCC... Don't want to make things worse for compilers that do it properly... +#define _MM_MALLOC_H_INCLUDED 1 -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
