Re: WITH_CLANG_BOOTSTRAP= for TARGET_ARCH=powerpc64 but bound to devel/powerpc64-binutils : can such be done?
[Looks like I misread something so. . .]
On 2016-Nov-27, at 4:34 PM, Mark Millard wrote:
> Currently head has switched to clang 3.9.0 but my
> TARGET_ARCH=powerpc64for clang experiments for buildworld are blocked
> by WITH_BINUTILS_BOOTSTRAP= 's ld stopping the buildworld via failing
> asserts.
>
> What I'd like to do is build the bootstrap clang but bound to a
> devel/powerpc64-binutils vintage to see if that works. So binutils
> being "cross tool chain" (even when directly invoked by clang) but
> clang itself not being cross tool chain but bootstrapped?
>
> (elftoolchain may need to be considered with binutils.)
>
> Do you know if there is a way for me to make assignments in a
> SRC_ENV_CONF file that might enable such a combination? Or
> do I need to modify the build environment to be non-standard?
>
> So far in my reading /usr/src/Makefile.inc1 I've not seen any
> combination of settings that look like it would go through and
> work for what I've described here.
I misread something and the following seems to have worked:
(I tend to be explicit about some things that I do not need
to be in such files: it helps em remember and understand some
issues.)
# more ~/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host
TO_TYPE=powerpc64
TOOLS_TO_TYPE=${TO_TYPE}
VERSION_CONTEXT=12.0
#
KERNCONF=GENERIC64vtsc-NODBG
TARGET=powerpc
.if ${.MAKE.LEVEL} == 0
TARGET_ARCH=${TO_TYPE}
.export TARGET_ARCH
.endif
#
WITH_CROSS_COMPILER=
WITHOUT_SYSTEM_COMPILER=
#
WITH_LIBCPLUSPLUS=
WITHOUT_BINUTILS_BOOTSTRAP=
WITH_CLANG_BOOTSTRAP=
WITH_CLANG=
WITH_CLANG_IS_CC=
WITH_CLANG_FULL=
WITH_CLANG_EXTRAS=
WITH_LLDB=
#
WITH_BOOT=
# world32/usr/src/lib/csu/powerpc/crti.o got:
# csu/powerpc/crti.S:34:13: error: unexpected token in memory operand
# csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic 'mflr'
# and the like. So avoid LIB32.
WITHOUT_LIB32=
#
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
WITHOUT_GCC_BOOTSTRAP=
WITHOUT_GCC=
WITHOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#WERROR=
MALLOC_PRODUCTION=
#
WITH_DEBUG_FILES=
#
#
# For TO (so-called "cross") stages . . .
# So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
# TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
#
CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
.if ${.MAKE.LEVEL} == 0
XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
#NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
.export XAS
.export XAR
.export XLD
.export XNM
.export XOBJCOPY
.export XOBJDUMP
.export XRANLIB
.export XSIZE
.export XSTRINGS
.endif
#
#
# From based on clang (via system). . .
#
.if ${.MAKE.LEVEL} == 0
CC=/usr/bin/clang
CXX=/usr/bin/clang++
CPP=/usr/bin/clang-cpp
.export CC
.export CXX
.export CPP
.endif
I have not tested what the buildworld produced yet.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
head -r309179 clang 3.9.0 for TARGET_ARCH=powerpc64 with devel/powerpc64-binutils used: WITH_LIB32= related assembler source rejected. . .
[Note: ld from WITH_BINTOOLS_BOOTSTRAP= for buildworld fails and stops buildworld. This explains the use of devel/powerpc64-binutils below.] Using clang 3.9.0 for TARGET_ARCH=powerpc64 with devel/powerpc64-binutils (of an appropriate vintage) apparently requires r1 instead of 1 for a register name --and so on. It turns out that trying to use WITH_LIB32= for TARGET_ARCH=powerpc64 with devel/powerpc64-binutils runs into assembler source files that are rejected for this reason. There are also complaints about invalid mnemonics (mflr and mr). The error reports: (Other files may well have the same sorts of problems.) > --- lib/csu__L --- > Building > /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o > . . . > --- crti.o --- > /usr/src/lib/csu/powerpc/crti.S:34:13: error: unexpected token in memory > operand > stwu 1,-16(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic > 'mflr' > mflr 0 > ^ > /usr/src/lib/csu/powerpc/crti.S:36:12: error: unexpected token in memory > operand > stw 31,12(1) >^ > /usr/src/lib/csu/powerpc/crti.S:37:11: error: unexpected token in memory > operand > stw 0,20(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:38:2: error: invalid instruction mnemonic 'mr' > mr 31,1 > ^ > /usr/src/lib/csu/powerpc/crti.S:45:13: error: unexpected token in memory > operand > stwu 1,-16(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:46:2: error: invalid instruction mnemonic > 'mflr' > mflr 0 > ^ > /usr/src/lib/csu/powerpc/crti.S:47:12: error: unexpected token in memory > operand > stw 31,12(1) >^ > /usr/src/lib/csu/powerpc/crti.S:48:11: error: unexpected token in memory > operand > stw 0,20(1) > ^ > /usr/src/lib/csu/powerpc/crti.S:49:2: error: invalid instruction mnemonic 'mr' > mr 31,1 > ^ > *** [crti.o] Error code 1 > > make[5]: stopped in /usr/src/lib/csu/powerpc > .ERROR_TARGET='crti.o' > .ERROR_META_FILE='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o.meta' > .MAKE.LEVEL='5' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > .CURDIR='/usr/src/lib/csu/powerpc' > .MAKE='make' > .OBJDIR='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc' > .TARGETS='all' > DESTDIR='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/lib32' > LD_LIBRARY_PATH='' > MACHINE='powerpc' > MACHINE_ARCH='powerpc' > MAKEOBJDIRPREFIX='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20160818' > PATH='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' > SRCTOP='/usr/src' > OBJTOP='/usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src' > .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk > /usr/src/share/mk/src.sys.env.mk > /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host > /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk > /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk > /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/csu/powerpc/Makefile > /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk > /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk > /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk > /usr/src/lib/csu/powerpc/../Makefile.inc > /usr/src/lib/csu/powerpc/../../Makefile.inc /usr/src/share/mk/bsd.own.mk > /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk > /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk > /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk > /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk > /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk /us r/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' > .PATH='. /usr/src/lib/csu/powerpc /usr/src/lib/csu/powerpc/../common' > --- lib/libc_nonshared__L --- > Building > /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/libc_nonshared/iconv.o > --- lib/csu__L --- > 1 error The .meta report: > # more > /usr/obj/powerpc64vtsc_clang_altbinutils_world/powerpc.powerpc64/usr/src/world32/usr/src/lib/csu/powerpc/crti.o.meta > # Meta data file > /usr/ob
[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863 Jan Beich (mail not working) changed: What|Removed |Added CC||port...@freebsd.org Attachment #177468||maintainer-approval?(portmg Flags||r...@freebsd.org) --- Comment #2 from Jan Beich (mail not working) --- Created attachment 177468 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=177468&action=edit gcc48 workaround Maybe dangerous if USES=compiler:gcc-c++11-lib is mixed with USES=fortran in dependencies. I've only tested direct consumers. graphics/GraphicsMagick had to be patched to avoid breaking science/gnudatalanguage: http://sprunge.us/bMYN -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
WITH_CLANG_BOOTSTRAP= for TARGET_ARCH=powerpc64 but bound to devel/powerpc64-binutils : can such be done?
Currently head has switched to clang 3.9.0 but my TARGET_ARCH=powerpc64for clang experiments for buildworld are blocked by WITH_BINUTILS_BOOTSTRAP= 's ld stopping the buildworld via failing asserts. What I'd like to do is build the bootstrap clang but bound to a devel/powerpc64-binutils vintage to see if that works. So binutils being "cross tool chain" (even when directly invoked by clang) but clang itself not being cross tool chain but bootstrapped? (elftoolchain may need to be considered with binutils.) Do you know if there is a way for me to make assignments in a SRC_ENV_CONF file that might enable such a combination? Or do I need to modify the build environment to be non-standard? So far in my reading /usr/src/Makefile.inc1 I've not seen any combination of settings that look like it would go through and work for what I've described here. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214855 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o ||rg -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 214862] head -r309197 clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214862 Mark Linimon changed: What|Removed |Added Keywords||regression Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o ||rg -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 214863] lang/gcc + libc++ may fail due to spurious __cxa_throw_bad_array_new_length reference
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org --- Comment #1 from Dimitry Andric --- This is because g++ 4.9 is now inserting a call to __cxa_throw_bad_array_new_length, e.g.: main: .LFB0: .cfi_startproc leal4(%esp), %ecx .cfi_def_cfa 1, 0 andl$-16, %esp pushl -4(%ecx) pushl %ebp .cfi_escape 0x10,0x5,0x2,0x75,0 movl%esp, %ebp pushl %ecx .cfi_escape 0xf,0x3,0x75,0x7c,0x6 subl$20, %esp movl$5, -12(%ebp) movl-12(%ebp), %eax addl$2, %eax cmpl$532676608, %eax ja .L2 sall$2, %eax jmp .L5 .L2: call__cxa_throw_bad_array_new_length but the support for this call was only merged to stable/10 in r278724, way after 10.1-R was created. One option is to compile the program without exception support, or to explicitly use gcc 4.8 or lower. I could not find a gcc command line option to disable the generation of these calls. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang 3.9.0 vs. TARGET_ARCH=powerpc: fsck_ufs and "df -m" are example failures: __floatdidf gets SIGSEGV's in both of them. [Code generation error involved.]
[This adds notes about a code generation error for r30 handling in what
FreeBSD's clang 3.9.0 generated for TARGET_ARCH=powerpc.]
On 2016-Nov-26, at 7:47 PM, Mark Millard wrote:
> [Short top post of where floatdidf definitions seem to be for
> TARGET_ARCH=powerpc.]
>
> libcompiler_rt , libc , and libgcc each seem to be places with
> floatdidf definitions:
>
> # grep floatdidf
> ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap_world-amd64-host-2016-11-26:11:38:36
> Building
> /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libcompiler_rt/floatdidf.o
> Building
> /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdidf.o
> Building
> /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdidf.pico
> Building
> /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/gnu/lib/libgcc/_floatdidf.pico
> Building
> /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libcompiler_rt/floatdidf.po
> Building
> /usr/obj/powerpcvtsc_clang_world/powerpc.powerpc/usr/src/lib/libc/floatdidf.po
>
> For .o:just libcompiler_rt and libc
> For .po: just libcompiler_rt and libc
> For .pico: just libgcc and libc
>
> Only libc is common to all 3 types of files. But the libc copy is
> not used by fsck_ufs or df. (The larger address routine is from
> /lib/libc.so.7 and the smaller one from the "local exec file".)
>
> I've no clue if this sort of thing is unique to powerpc or not.
Independent of the above potential issue I've added a new comment to llvm's
26519 about the code generated for compiler_rt's __floatdidf being wrong:
it misuses r30. . .
Unfortunately there are problems handling use of r30, at least when floating
point is involved.
The used code from the compliler_rt __floatdidf seems to be just wrong in part
of its use of r30. The below initially uses the "df -m" example failure and its
code.
At first is saves r30 on the stack as part of the function preamble:
Dump of assembler code for function __floatdidf:
0x018029b8 <__floatdidf+0>: mflrr0
0x018029bc <__floatdidf+4>: stw r0,4(r1)
0x018029c0 <__floatdidf+8>: stwur1,-32(r1)
0x018029c4 <__floatdidf+12>:stw r31,28(r1)
0x018029c8 <__floatdidf+16>:stw r30,24(r1)
Later it uses r30 for other things.
Then it restores it from the stack:
0x01802a08 <__floatdidf+80>:lwz r30,24(r1)
What it does with r30 next effectively makes r30 a parameter to the routine and
not just saved/restored:
0x01802a10 <__floatdidf+88>:lwz r3,-8(r30)
In the above the r30 from the caller's context is being used as the base for
accessing memory and putting that memory content in r3.
What it does next with r3 is one of the points where SIGSEGV is happening: For
"df -m" r3 ends up being 0 and the following fails.
0x01802a18 <__floatdidf+96>:lfs f12,0(r3)
In the fsck_ufs example it is the same sort of thing but r30 happens to be
initially 0 so it fails at an earlier stage.
Again there is the preamble that saves r30:
0x0181afcc <__floatdidf+0>: mflrr0
0x0181afd0 <__floatdidf+4>: stw r0,4(r1)
0x0181afd4 <__floatdidf+8>: stwur1,-32(r1)
0x0181afd8 <__floatdidf+12>:stw r31,28(r1)
0x0181afdc <__floatdidf+16>:stw r30,24(r1)
Later it uses r30 for other things.
Then it restores it from the stack:
0x0181b01c <__floatdidf+80>:lwz r30,24(r1)
What it does with r30 next effectively makes r30 a parameter to the routine and
not just saved/restored:
0x0181b024 <__floatdidf+88>:lwz r3,-12(r30)
Again: In the above the r30 from the caller's context is being used as the base
for accessing memory and putting that memory content in r3.
But this time it turns out that r30 is 0 and the above also fails.
If the code had gotten that far it would have done the same thing with r3 that
"df -m" did in its failure:
0x0181b02c <__floatdidf+96>:lfs f12,0(r3)
For reference compiler-rt/lib/builtins/floatdidf.c has:
COMPILER_RT_ABI double
__floatdidf(di_int a)
{
static const double twop52 = 4503599627370496.0; // 0x1.0p52
static const double twop32 = 4294967296.0; // 0x1.0p32
union { int64_t x; double d; } low = { .d = twop52 };
const double high = (int32_t)(a >> 32) * twop32;
low.x |= a & INT64_C(0x);
const double result = (high - twop52) + low.d;
return result;
}
and the matching assembler code for the fsck_ufs example is (from gdb):
===
Mark Millard
markmi at dsl-only.net
On 2016-Nov-26, at 4:41 PM, Mark Millard wrote:
> [Summary: Looking around with gdb at fsck_ufs I found two __floatdidf routines
> with different code. df has the same.]
>
> On 2016-Nov-26, at 3:39 PM, Mark Millard wrote:
>
>> I updated to head -r309197 (with a work around for -r309144 breaking the
>> build).
>>
>> This was on amd64, then used it to try to cross buildworld using clang 3.9.0
>> for
>> TARGET_ARCH=powerpc . The build completed. (I've been using
