This is the mail archive of the
mailing list for the binutils project.
Re: PR ld/12637: reloc overflow for R_MIPS_TLS_LDM
- From: Tristan Gingold <gingold at adacore dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: binutils at sourceware dot org
- Date: Mon, 18 Apr 2011 09:46:02 +0200
- Subject: Re: PR ld/12637: reloc overflow for R_MIPS_TLS_LDM
- References: <firstname.lastname@example.org>
On Apr 10, 2011, at 1:10 PM, Richard Sandiford wrote:
> This patch fixes PR ld/12637, which is about relocation overflow
> in a libjava link. The problem is that we end up having TLS entries
> in a primary GOT that is too big for them. There was code to try
> to handle this case:
> /* We place TLS GOT entries after both locals and globals. The globals
> for the primary GOT may overflow the normal GOT size limit, so be
> sure not to merge a GOT which requires TLS with the primary GOT in that
> case. This doesn't affect non-primary GOTs. */
> estimate += (g->tls_gotno > 0 ? arg->global_count : g->global_gotno);
> if (estimate <= arg->max_count)
> /* If we don't have a primary GOT, use it as
> a starting point for the primary GOT. */
> if (!arg->primary)
> arg->primary = bfd2got->g;
> return 1;
> /* Try merging with the primary GOT. */
> result = mips_elf_merge_got_with (bfd2got, arg->primary, arg);
> if (result >= 0)
> return result;
> which works fine when the GOT we're adding has TLS entries. But we
> also need to handle the case where we're adding a GOT that doesn't
> have TLS entries to a primary GOT that already does.
> The bug has been around for a long time (probably since the inception
> of TLS), but 2.20 did not fail for this particular testcase.
> In the testcase, the number of global GOT entries is pretty close to
> the threshold beyond which the primary GOT can no longer be assigned
> to input bfds. I think the changes to more accurately estimate the
> other parts of the GOT (the non-global parts) mean that we are now able
> to use the primary GOT for some bfds, whereas previously we couldn't.
> One of the first GOTs we add has TLS entries. We correctly estimate
> that it can be merged into the primary GOT. We then tried to add lots
> of other GOTs that don't have TLS entries, and the number of local
> entries we added then pushed the TLS entries out of range.
> Tested on mips64-linux-gnu and applied. Tristan, is this OK for
> the branch?