svn commit: r318750 - in head/contrib: binutils/bfd binutils/ld binutils/ld/emulparams gcc gcc/config/s390
Bryan Drewery
bdrewery at FreeBSD.org
Mon Jun 5 05:19:03 UTC 2017
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 at 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 at FreeBSD.org> schrieb:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> This is no-op and only for reference: the S/390 port seems to be elusive
>>>>>> in the BSDs so it is convenient to keep some trace from past efforts.
>>>>>> It is likely newer attempts will focus on a newer toolchain using clang
>>>>>> instead.
>>>>>>
>>>>>> Obtained from: Perforce depot/projects/s390
>>>>>>
>>>>>> Added:
>>>>>> head/contrib/binutils/ld/emulparams/elf64_s390_fbsd.sh (contents, props changed)
>>>>>> head/contrib/binutils/ld/emulparams/elf_s390_fbsd.sh (contents, 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
>>>> ...
>>>>>> Buildworld fails on r318751 with a "Segmentation fault" error as shown 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='skein_block_asm.o'
>>>>>> .ERROR_META_FILE='/usr/obj/usr/src/lib/libmd/skein_block_asm.o.meta'
>>>>>> .MAKE.LEVEL='4'
>>>>>> MAKEFILE=''
>>>>>>
>>>>>>
>>>>>> Host is running recent CURRENT: FreeBSD 12.0-CURRENT #124 r318748: Tue May 23
>>>>>> 18:52:59 CEST 2017 amd64
>>>>
>>>> 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 (the
>>>> 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 start 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 host
>> and then doing another build, your ld and various other host tools will
>> 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 get
>> 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 rebuild
>> 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 files:
>>
>>> -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.
>
> This commit did cause a mixed-ABI object issue that I predicted.
>
> Built before, updated, built again and targets.o is rebuilt.
>
>> 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
>
> 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 of
> the changes structs that I can see, but the mixed-ABI proof is enough
> for me to put the understanding of this to rest.
>
> In case I wasn't clear, this commit is perfectly fine. It just
> triggered a META_MODE bug.
>
>
>>
>> Anyway the fix for this would be to either 'make cleanworld' after
>> upgrading to ino64, use -DNO_META_IGNORE_HOST for the first build after,
>> 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 due
>> 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.
>>
>
>
I committed a workaround for all of this in r319594. META_MODE should
properly rebuild host tools for the ino64 case now.
--
Regards,
Bryan Drewery
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20170604/574db703/attachment-0001.sig>
More information about the svn-src-all
mailing list