From: Daniel Jacobowitz <drow@mvista.com>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: binutils@sources.redhat.com
Subject: Re: Another MIPS multigot patch
Date: Sun, 23 Nov 2003 01:24:00 -0000 [thread overview]
Message-ID: <20031123012406.GA11321@nevyn.them.org> (raw)
In-Reply-To: <874qwwusg1.fsf@redhat.com>
On Sat, Nov 22, 2003 at 07:14:06PM +0000, Richard Sandiford wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> > I'm using GCC 3.3.1, FYI. So it may be fixed in HEAD which I'm not
> > really set up to try at the moment. The relocation comes from:
> > lw $2,flag_dump_unnumbered
>
> Ah, never mind then. ;) I assumed this was gcc explicit-reloc output.
>
> > We're in mips_elf_global_got_index, looking at this symbol. It has
> > h->dynindx of around 3500, and global_got_dynindx is 5. g->local_gotno
> > is about 5000. So we have an overflow; that's more than 8K 8-byte
> > entries. Are you saying that the fact that there are R_MIPS_GOT_PAGE
> > entries against flag_dump_unnumbered using the primary GOT means it
> > should have a lower dynindx?
>
> Well, there are two ways we can handle the relocation:
>
> 1. Decay to R_MIPS_GOT_DISP. In that case, yes, the index
> should be lower.
>
> 2. Use a local page entry.
>
> (2) should be possible in this case, and looking at the code,
> it does seem like we try to support it.
>
> It's difficult to be sure without access to the test case, so this is
> probably completely wrong. But I'm guessing the problem is:
I can package up the testcase if you want. It's a bit large. In the
mean time, I'll look at this more tomorrow or Monday but:
> (a) _bfd_mips_elf_check_relocs assumes print-rtl.c can use a local
> page entry for GOT_PAGE/GOT_OFST accesses to flag_dump_unnumbered.
> f_d_u is therefore not entered into print-rtl's got_entries.
>
> (b) toplev uses GOT_DISP, so we end up needing a global GOT
> entry for f_d_u.
000000001028 00a900000012 R_MIPS_64 0000000000000000 flag_dump_unnumbered + 0
Type2: R_MIPS_NONE
Type3: R_MIPS_NONE
So, close enough for our purposes.
> (c) Because of (a), no bfd that uses the primary GOT seems to need
> an entry for f_d_u. We therefore give it a higher index than
> symbols that _do_ need an entry.
>
> (d) Because of (c), mips_elf_calculate_relocation assumes that f_d_u
> is !local_p, and it therefore decays the GOT_PAGE reloc into a
> GOT_DISP. So print-rtl uses f_d_u's GOT entry after all.
>
> If so, then IMO the bug is with (d). We can still use local pages
> for print-rtl, despite the entry in .dynsym.
This all makes sense to me. I'll think about what the local_p
condition really ought to be. This:
case R_MIPS_GOT_PAGE:
case R_MIPS_GOT_OFST:
/* If this symbol got a global GOT entry, we have to decay
GOT_PAGE/GOT_OFST to GOT_DISP/addend. */
local_p = local_p || ! h
|| (h->root.dynindx
< mips_elf_get_global_gotsym_index (elf_hash_table (info)
needs to become... I'm not quite sure what. Is it reasonable to use
SYMBOL_REFERENCES_LOCAL here?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-11-23 1:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-21 22:17 Daniel Jacobowitz
2003-11-22 16:30 ` Richard Sandiford
2003-11-22 17:40 ` Daniel Jacobowitz
2003-11-22 19:13 ` Richard Sandiford
2003-11-23 1:24 ` Daniel Jacobowitz [this message]
2004-01-29 14:46 ` Daniel Jacobowitz
2004-01-29 15:55 ` Richard Sandiford
2004-01-29 16:19 ` Daniel Jacobowitz
2004-01-29 17:39 ` Richard Sandiford
2004-01-29 18:03 ` Daniel Jacobowitz
2004-01-31 21:13 ` Richard Sandiford
2004-02-10 22:59 ` Daniel Jacobowitz
2004-02-11 8:19 ` Richard Sandiford
2004-02-15 13:46 ` Richard Sandiford
2004-02-15 18:42 ` Daniel Jacobowitz
2004-02-15 22:00 ` Richard Sandiford
2004-02-16 3:17 ` Daniel Jacobowitz
2004-02-16 8:06 ` Richard Sandiford
2004-02-16 18:37 ` Daniel Jacobowitz
2004-02-17 9:17 ` RFA: " Richard Sandiford
2004-02-17 9:27 ` Richard Sandiford
2004-02-17 10:07 ` Eric Christopher
2004-02-17 15:17 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031123012406.GA11321@nevyn.them.org \
--to=drow@mvista.com \
--cc=binutils@sources.redhat.com \
--cc=rsandifo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).