From owner-freebsd-mips@FreeBSD.ORG Sat Jul 26 11:46:32 2014 Return-Path: Delivered-To: freebsd-mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03512689; Sat, 26 Jul 2014 11:46:32 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B624923CE; Sat, 26 Jul 2014 11:46:31 +0000 (UTC) Received: from [192.168.0.7] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s6QBkIVR001667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 26 Jul 2014 11:46:20 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mips64 ld GOT problem From: David Chisnall In-Reply-To: Date: Sat, 26 Jul 2014 12:46:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2021F70B-2AA4-412C-8D1B-A8D38A3E031C@FreeBSD.org> References: <77F1DDA2-A4E5-4D64-AA43-F8CBC55249C4@me.com> <48935A3D-0387-42F1-ACF0-14EB7D8F9A06@bsdimp.com> To: Stacey Son X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-mips@FreeBSD.org X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 11:46:32 -0000 The only way that I've ever got llvm to compile for MIPS has been by = enabling shared libraries, enabling optimisation, and disabling debug = info. This gave each shared lib a small enough GOT for our binutils = linker to work. Newer binutils supports multi-GOT (GOT is split and different GOTs are = installed by some calls) and large-GOT (GOT accesses use register = offsets) modes. David On 25 Jul 2014, at 23:27, Stacey Son wrote: >=20 > Hi Warner... >=20 > On Jul 25, 2014, at 11:26 AM, Warner Losh wrote: >=20 >>=20 >> On Jul 25, 2014, at 9:24 AM, Stacey Son wrote: >>=20 >>> Hi all: >>>=20 >>> I have been trying to bootstrap clang/llvm 3.5 for mips64 (i.e. = cross build clang/llvm 3.5 for mips64 using clang/llvm 3.5) but run into = the following linker problem (see below) in about the midway point as it = is trying to link 'opt'. The assertions that fail are the following: >>>=20 >>> BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail = /usr/home/sson/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/bin= utils/bfd/elfxx-mips.c:7455 >>>=20 >>> BFD_ASSERT (g->assigned_gotno - g->local_gotno >>> <=3D g->global_gotno); >>>=20 >>> BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail = /usr/home/sson/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/bin= utils/bfd/elfxx-mips.c:2767 >>>=20 >>> /* There should have been enough room in the symbol table to >>> accommodate both the GOT and non-GOT symbols. */ >>> BFD_ASSERT (hsd.max_non_got_dynindx <=3D hsd.min_got_dynindx); >>>=20 >>> BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail = /usr/home/sson/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/bin= utils/bfd/elfxx-mips.c:10282 >>>=20 >>> /* Make sure we didn't grow the global .got region. */ >>> dynobj =3D elf_hash_table (info)->dynobj; >>> got =3D mips_elf_got_section (dynobj, FALSE); >>> g =3D mips_elf_section_data (got)->u.got_info; >>>=20 >>> if (g->global_gotsym !=3D NULL) >>> BFD_ASSERT ((elf_hash_table (info)->dynsymcount >>> - g->global_gotsym->dynindx) >>> <=3D g->global_gotno); >>>=20 >>> Does anyone have an idea for a work around or fix? >>=20 >> Silly question: does using the latest binutils fix this problem? >=20 > Is there a stable port of the latest binutils to mips? Does someone = have some patches? I did tried TheRaven's port of the 2.18 binutils but = it seemed that 'ld' wasn't very happy. It didn't like any of the object = files I offered it. >=20 >> Failing that, perhaps we need to specify a larger GOT region that we = do today? IIRC, that=92s specified with -g on the linker line, Try = adding =93-G0=94. I have a vague recollection we always used to do this, = but moved it to be a default (or maybe other systems have the default = and we still need to add it). It doesn=92t look like it is being added = from the output that you=92ve posted. IIRC, it has to be specified on = all the compiler invocations as well. >=20 > Reading the man page implies -Gvalue/--gpsize=3Dvalue is only for = ECOFF binaries. I tried it anyway and it didn't seem to help. >=20 > -stacey.