Date: Sun, 4 Jun 2017 22:18:37 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: "O. Hartmann" <ohartmann@walstatt.org>, Pedro Giffuni <pfg@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Navdeep Parhar <np@FreeBSD.org> Subject: Re: svn commit: r318750 - in head/contrib: binutils/bfd binutils/ld binutils/ld/emulparams gcc gcc/config/s390 Message-ID: <7b9764ae-b00d-c387-12b7-a8b12808295a@FreeBSD.org> In-Reply-To: <ccae60b9-91ab-951b-8f6e-8948352aae06@FreeBSD.org> References: <201705231638.v4NGcAq1005935@repo.freebsd.org> <20170523191129.57183b1c@thor.intern.walstatt.dynvpn.de> <5d1d0149-7994-a870-0f6d-1499a9efba75@FreeBSD.org> <20170523210039.555a2f41@thor.intern.walstatt.dynvpn.de> <768df353-3e43-1da7-4a94-0acc1c741ad4@FreeBSD.org> <ccae60b9-91ab-951b-8f6e-8948352aae06@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GWeq3P6s4tjTdmeLxvqSnR2hj3mVaJ7O2 Content-Type: multipart/mixed; boundary="JU8F9oGabpJfLGPcmmOMLWhScVenEbGcM"; protected-headers="v1" From: Bryan Drewery <bdrewery@FreeBSD.org> To: "O. Hartmann" <ohartmann@walstatt.org>, Pedro Giffuni <pfg@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Navdeep Parhar <np@FreeBSD.org> Message-ID: <7b9764ae-b00d-c387-12b7-a8b12808295a@FreeBSD.org> Subject: Re: svn commit: r318750 - in head/contrib: binutils/bfd binutils/ld binutils/ld/emulparams gcc gcc/config/s390 References: <201705231638.v4NGcAq1005935@repo.freebsd.org> <20170523191129.57183b1c@thor.intern.walstatt.dynvpn.de> <5d1d0149-7994-a870-0f6d-1499a9efba75@FreeBSD.org> <20170523210039.555a2f41@thor.intern.walstatt.dynvpn.de> <768df353-3e43-1da7-4a94-0acc1c741ad4@FreeBSD.org> <ccae60b9-91ab-951b-8f6e-8948352aae06@FreeBSD.org> In-Reply-To: <ccae60b9-91ab-951b-8f6e-8948352aae06@FreeBSD.org> --JU8F9oGabpJfLGPcmmOMLWhScVenEbGcM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/1/17 5:51 PM, Bryan Drewery wrote: > On 6/1/2017 5:18 PM, Bryan Drewery wrote: >> On 5/23/2017 12:00 PM, O. Hartmann wrote: >>> Am Tue, 23 May 2017 12:52:35 -0500 >>> Pedro Giffuni <pfg@FreeBSD.org> schrieb: >>> >>>> On 23/05/2017 12:12, O. Hartmann wrote: >>>>> Am Tue, 23 May 2017 16:38:10 +0000 (UTC) >>>>> "Pedro F. Giffuni" <pfg@FreeBSD.org> schrieb: >>>>> =20 >>>>>> Author: pfg >>>>>> Date: Tue May 23 16:38:10 2017 >>>>>> New Revision: 318750 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/318750 >>>>>> >>>>>> Log: >>>>>> Bring some rough support for FreeBSD S/390 to the GNU toolchain= =2E >>>>>> =20 >>>>>> This is no-op and only for reference: the S/390 port seems to b= e elusive >>>>>> in the BSDs so it is convenient to keep some trace from past ef= forts. >>>>>> It is likely newer attempts will focus on a newer toolchain usi= ng clang >>>>>> instead. >>>>>> =20 >>>>>> Obtained from: Perforce depot/projects/s390 >>>>>> >>>>>> Added: >>>>>> head/contrib/binutils/ld/emulparams/elf64_s390_fbsd.sh (conte= nts, props changed) >>>>>> head/contrib/binutils/ld/emulparams/elf_s390_fbsd.sh (content= s, props changed) >>>>>> head/contrib/gcc/config/s390/freebsd.h >>>>>> - copied, changed from r318546, head/contrib/gcc/config/s390= /linux.h >>>>>> Modified: >>>>>> head/contrib/binutils/bfd/config.bfd >>>>>> head/contrib/binutils/ld/configure.tgt >>>>>> head/contrib/gcc/config.gcc =20 >>>> ... >>>>>> Buildworld fails on r318751 with a "Segmentation fault" error as s= hown below: >>>>>> >>>>>> Building /usr/obj/usr/src/lib/libkiconv/_libinstall >>>>>> --- lib/libmd__L --- >>>>>> --- skein_block_asm.o --- >>>>>> Segmentation fault >>>>>> *** [skein_block_asm.o] Error code 139 >>>>>> >>>>>> make[4]: stopped in /usr/src/lib/libmd >>>>>> .ERROR_TARGET=3D'skein_block_asm.o' >>>>>> .ERROR_META_FILE=3D'/usr/obj/usr/src/lib/libmd/skein_block_asm.o.m= eta' >>>>>> .MAKE.LEVEL=3D'4' >>>>>> MAKEFILE=3D'' >>>>>> >>>>>> >>>>>> Host is running recent CURRENT: FreeBSD 12.0-CURRENT #124 r318748:= Tue May 23 >>>>>> 18:52:59 CEST 2017 amd64 =20 >>>> >>>> It shouldn't be related to this change: >>>> >>>> 1) This only affects s390 configuration which is never activated >>>> 2) I did run a tinderbox build to make sure nothing was affected (th= e=20 >>>> only thing failing was an unrelated powerpc warning that was fixed).= >>>> >>>> Pedro. >>> >>> Hello, >>> >>> the problem could be resolved by deleting the /usr/obj folder and sta= rt a clean build >>> again. >>> >> >> I think this is fallout from ino64 combined with META_MODE. META_MODE= >> assumes that host tools will be ABI-compatible and generally does not >> [force] rebuild them very often. So the act of upgrading to ino64 hos= t >> and then doing another build, your ld and various other host tools wil= l >> still be running pre-ino64 binaries via COMPAT_FREEBSD11. I think the= >> bug in this system is that it is possible for some of these tools to g= et >> mixed-ABI objects linked together resulting in differing ideas of what= >> 'struct stat' is for example. This could be possible since META_MODE >> won't force rebuild all objects for a directory/tool but it may rebuil= d >> 1 object for some reason or just relink the resulting binary. >> >> Here's an example of what I'm talking about with the host ld object fi= les: >> >>> -rwxr-xr-x 1 root wheel 1857312 Jun 1 12:59 ld.bfd* = >>> -rwxr-xr-x 1 root wheel 931304 Jun 1 12:59 ld.bfd.debug* = >>> -rw-r--r-- 1 root wheel 978 Jun 1 12:59 ld.bfd.debug.meta = >>> -rwxr-xr-x 1 root wheel 2600311 Jun 1 12:59 ld.bfd.full* = >>> -rw-r--r-- 1 root wheel 3988 Jun 1 12:59 ld.bfd.full.meta = >>> -rw-r--r-- 1 root wheel 999 Jun 1 12:59 ld.bfd.meta = >>> -rw-r--r-- 1 root wheel 154400 Apr 18 16:12 ldcref.o = >>> -rw-r--r-- 1 root wheel 4553 Apr 18 16:12 ldcref.o.meta = >>> -rw-r--r-- 1 root wheel 137088 May 11 14:14 ldctor.o = >>> -rw-r--r-- 1 root wheel 4348 May 11 14:14 ldctor.o.meta = >>> -rw-r--r-- 1 root wheel 205 Oct 11 2016 ldemul-list.h = >>> -rw-r--r-- 1 root wheel 814 Oct 11 2016 ldemul-list.h.meta = >>> -rw-r--r-- 1 root wheel 144088 Oct 13 2016 ldemul.o = >>> -rw-r--r-- 1 root wheel 4374 Oct 13 2016 ldemul.o.meta = >> >> The object files predate ino64 but the linked binaries do not. I did >> not dig into these object files more but I suspect somewhere there are= >> mixed-ABI object files hitting this bug or that just linking pre-ino64= >> objects may cause a problem. I don't think linking would be a problem= >> though. >=20 > This commit did cause a mixed-ABI object issue that I predicted. >=20 > Built before, updated, built again and targets.o is rebuilt. >=20 >> Building /usr/obj/root/svn/base/gnu/usr.bin/binutils/libbfd/targmatch.= h >> Skipping meta for .depend: no commands >> Skipping meta for afterdepend: .PHONY >> Skipping meta for depend: .PHONY >> Skipping meta for objwarn: .PHONY >> Skipping meta for beforebuild: .PHONY >> Skipping meta for .WAIT_1: .PHONY >> /usr/obj/root/svn/base/gnu/usr.bin/binutils/libbfd/targets.o.meta: 81:= file '/usr/obj/root/svn/base/gnu/usr.bin/binutils/libbfd/./targmatch.h' = is newer than the target... >> Building /usr/obj/root/svn/base/gnu/usr.bin/binutils/libbfd/targets.o >=20 > targets.o is the only relevant object file I could find in the broken > objtree given to me that was post-ino64. It doesn't directly use any o= f > the changes structs that I can see, but the mixed-ABI proof is enough > for me to put the understanding of this to rest. >=20 > In case I wasn't clear, this commit is perfectly fine. It just > triggered a META_MODE bug. >=20 >=20 >> >> Anyway the fix for this would be to either 'make cleanworld' after >> upgrading to ino64, use -DNO_META_IGNORE_HOST for the first build afte= r, >> or wait for my fix. I will commit a fix to force rebuild host tools >> through known major ABI changes to avoid this problem. >> >> For discussion of why META_MODE tries to not rebuild host tools see >> r301467. The gist is that a simple >> 'buildworld->installworld->buildworld' causes everything to rebuild du= e >> to changed host file timestamps. Really it would be better if >> filemon/META_MODE used file content hashing like ccache did. Then >> timestamps wouldn't cause such a problem here. >> >=20 >=20 I committed a workaround for all of this in r319594. META_MODE should properly rebuild host tools for the ino64 case now. --=20 Regards, Bryan Drewery --JU8F9oGabpJfLGPcmmOMLWhScVenEbGcM-- --GWeq3P6s4tjTdmeLxvqSnR2hj3mVaJ7O2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZNOmtAAoJEDXXcbtuRpfPAe4IAIrqRaetXn9W+7qCoqYMdxXc dZU5mHeK1b9R/qtNY94H8r3tx9OJdHNyYESZ4lJjcXQLn9Nyvrq16QKZ1yiN19C4 gLAc5Nexof9q2XTeBXXgqTJjkClYqeyJLRG7t9Zhbxfm+4/zWlOOEGBJzVuy8Mms qIMw7EMqCZ76n/Ddd+d+z73199JNCd3ll11JwSBppuoNilUvVgUUoWnX4wl5I2A6 Lj9OL8Ry1m2EJ1th+p7PgZb5XFPs0d4uYQ7xFNFA9b1FaQtaVF2f62Q6rg8XRI4H Uhzpl9L15oqkhS4u+d86vyhv56EaDCB8n+ArL4qdqIJnBh2PLRo+nSQax9L0mdM= =nmyp -----END PGP SIGNATURE----- --GWeq3P6s4tjTdmeLxvqSnR2hj3mVaJ7O2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7b9764ae-b00d-c387-12b7-a8b12808295a>