Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Jul 2014 12:46:14 +0100
From:      David Chisnall <theraven@FreeBSD.org>
To:        Stacey Son <sson@FreeBSD.org>
Cc:        freebsd-mips@FreeBSD.org
Subject:   Re: mips64 ld GOT problem
Message-ID:  <2021F70B-2AA4-412C-8D1B-A8D38A3E031C@FreeBSD.org>
In-Reply-To: <C7869A0A-8CE6-4764-9AFD-A49C93E680C1@FreeBSD.org>
References:  <77F1DDA2-A4E5-4D64-AA43-F8CBC55249C4@me.com> <48935A3D-0387-42F1-ACF0-14EB7D8F9A06@bsdimp.com> <C7869A0A-8CE6-4764-9AFD-A49C93E680C1@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <sson@FreeBSD.org> wrote:

>=20
> Hi Warner...
>=20
> On Jul 25, 2014, at 11:26 AM, Warner Losh <imp@bsdimp.com> wrote:
>=20
>>=20
>> On Jul 25, 2014, at 9:24 AM, Stacey Son <sson@me.com> 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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2021F70B-2AA4-412C-8D1B-A8D38A3E031C>