public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rdsandiford@googlemail.com>
To: Jack Carter <Jack.Carter@imgtec.com>
Cc: "binutils\@sourceware.org" <binutils@sourceware.org>,
	 "libc-alpha\@sourceware.org" <libc-alpha@sourceware.org>,
	 "macro\@codesourcery.com" <macro@codesourcery.com>
Subject: Re: Description of MIPS/IRIX multigot
Date: Tue, 18 Mar 2014 08:39:00 -0000	[thread overview]
Message-ID: <87mwgnhpem.fsf@talisman.default> (raw)
In-Reply-To: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6FB67C@BADAG02.ba.imgtec.org>	(Jack Carter's message of "Mon, 17 Mar 2014 22:39:33 +0000")

Jack Carter <Jack.Carter@imgtec.com> writes:
> I am retiring in a few days

Congratulations!  All the best for your retirement.  And thanks for
the write-up.

> * It follows the ELF philosophy of packaging data in an orderly fashion. The
>   different elements of the GOT are no longer just LOCAL and GLOBAL. 
>   Visibility like Protected, hidden and global are separated and 
>   specifically pointed to. This helped post linkage instrumentation tools
>   like pixie do the right thing. 

I don't buy this though.  Visibility information is already given by the
symbol table.  There's no need to duplicate it in the GOT tags.

> Yes I know, you can get it working without all of the above
> information, but why make a tough job tougher?

Heh, well, I know I'm going over old ground, but this sounds like it
_is_ making a tough job tougher :-)  We already support the same thing
(bar lazy binding in secondary GOTs) for GNU/Linux, in a much simpler
way and without having had to extend the ABI, or surprise generic ELF
readers by having several .dynamic sections.

The way that the original psABI tied global symbols to the GOT was a
nice trick for saving space and providing a free cache, but when it
comes to secondary GOTs, the advantage seems the other way: having
a relocation per GOT entry is simpler, more safe-efficient and quicker
at load time than adding extra .dynamic sections and duplicating part of
the symbol table.  The missing feature of lazy binding in secondary GOTs
could be handled by relocations too; the net effect would still be
simpler than having several .dynamics.

So IMO, while the psABI got it right by having an efficient way of
handling simple local and global entries, other targets got it right
by allowing the GOT to be just a bunch of data that can be relocated
like any other.  This includes relocs that weren't envisaged at the time,
like TLS and ifunc.

So I think the guys who added MIPS TLS made the right call by having the
TLS GOT entries be relocated normally.  And I think it's the right call
for ifunc too.

I still think it would be good to allow these normally-relocated entries
in the main part of the GOT though, rather than having to tack them on
after all the ABI-mandated global GOT entries (including those that are
needed only because there's a relocation against a particular global
symbol).  As we discussed before, all that needs is a new tag.

Thanks,
Richard

  reply	other threads:[~2014-03-18  8:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-17 22:39 Jack Carter
2014-03-18  8:39 ` Richard Sandiford [this message]
2014-03-18 17:54   ` Jack Carter
2014-03-18 18:54     ` Maciej W. Rozycki

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=87mwgnhpem.fsf@talisman.default \
    --to=rdsandiford@googlemail.com \
    --cc=Jack.Carter@imgtec.com \
    --cc=binutils@sourceware.org \
    --cc=libc-alpha@sourceware.org \
    --cc=macro@codesourcery.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).