svn commit: r318750 - in head/contrib: binutils/bfd binutils/ld binutils/ld/emulparams gcc gcc/config/s390

[Bryan Drewery]

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.
> 


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170601/574defbb/attachment.sig>