This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: invocation of mips_elf_multi_got can cause not enough GOT space for local GOT entries
On Wed, Jan 9, 2013 at 4:09 PM, Robert Schiele <rschiele@gmail.com> wrote:
> On Tue, Jan 8, 2013 at 8:15 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Sorry, it's going to very hard to help here without a testcase.
>
> Yes, I feared so. I was just hoping that you might have an immediate
> idea from the information collection. I am trying to produce a
> non-proprietary test case now that I can easily hand out.
Ok, finally I have one but it is not really a small one. Given that it
seems only possible to trigger that for links large enough to involve
the code handling the case a single GOT gets too large I ended up with
something that is compressed about 6.5M. You can download the beast
here: http://sdrv.ms/VPT3hi
Note that this is partially auto generated ELF data and I am not
perfectly sure whether it is 100% standards compliant but at least
libbfd does not seem to complain about it (besides the error mentioned
here that I can also reproduce with gcc generated stuff).
You need to unpack the test case into some empty directory. Inside you
will find some object files, some static libraries and some shared
libraries. Additionally there is a script "reproduce" that tries to
reproduce the problem. You have to adapt the name of the linker you
want to use. I built mine with /home/rschiele/src/binutils/configure
--target=mips64-octeon-linux-gnu --with-sysroot=/xxxx
Should some of the auto generated stuff be too much confusing feel
free to ask specific questions such that I could do corresponding
investigations on the real proprietary code.
As already mentioned in my mail from yesterday I feel pretty certain
now that the calculation for the upper bound of GOT pages is not
correct for the case of sections that get merged (like string pools)
since their range can expand during the merge and thus a set of
relocations can cover more pages afterwards than it did before. But I
am not sure yet what a correct upper bound would be in that case that
would not hurt the regular case too much.
Robert