public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Cary Coutant <ccoutant@gmail.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Nick Clifton <nickc@redhat.com>,
	gnu-gabi@sourceware.org, 	"H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: RFA: Add a new gynamic tag: DT_GNU_GOT_PLT_END
Date: Mon, 01 Jan 2018 00:00:00 -0000	[thread overview]
Message-ID: <CAJimCsETsrMRw8DuAngVR-EwJ_L9=yJGAcWnEdDhRNZQ-0+1qQ@mail.gmail.com> (raw)
In-Reply-To: <a9b4fb9b-382f-a1ad-f1aa-99a11254f09f@redhat.com>

>> Fourth: Isn't the size of .got.plt inferrable from DT_PLTRELSZ? Divide
>> that by the size of each relocation (DT_PLTREL == DT_REL ? DT_RELENT :
>> DT_RELAENT), then multiply by the size of the PLTGOT entry (4 or 8),
>> then add the three reserved entries. There's a one-to-one relationship
>> between the PLT and the PLTGOT, and every PLTGOT entry must have a
>> relocation.
>
> The PLT count wouldn't include the padding at the end of the section, so it
> doesn't confer the required information.

That plus a simple flag does, though.

>> Fifth: If all you're trying to say is "the .got.plt section is
>> isolated on its own pages", couldn't you just use one of the DT_FLAGS
>> or DT_FLAGS_1? Letting the presence of an END or SZ entry signal this
>> condition is a bit risky -- what if someone decides they'd like to
>> record the size of .got.plt even when it's not isolated on its own
>> pages?
>
> Well, isn't this a problem no matter what we specify?  That someone might
> provide incorrect information?  If we use a number, at least disagreement
> about the run-time page size isn't a source of potential issues.

My point is that a DT_PLTGOTSZ entry could be useful on its own to
indicate the size of the PLT GOT. If you make it *also* imply that the
PLT GOT is isolated on its own pages, you're pre-empting that meaning
of the tag (which, given the name, would be the most obvious meaning).
Although I guess DT_PLTGOTSZ could be taken to mean: "Here's the size
of the PLT GOT, possibly including any trailing padding intended to
pad it out to a page boundary. If it works out that the beginning and
end of the segment are both at page boundaries, then it's possible to
make it relro." In other words, the tag's presence doesn't -- on its
own -- imply that the PLT GOT has been placed on separate pages, but
provides the information to determine whether it has.

That leads me to another question: How would this be different from -z
relro -z now? It looks to me like a binary with such a PLT GOT would
be nothing more than a -z relro -z now binary where nothing but the
.got.plt section ends up as RELRO. So why not just use the
PT_GNU_RELRO program header for this?

-cary

  reply	other threads:[~2018-06-24 18:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87sh5hadd6.fsf@redhat.com>
     [not found] ` <CAMe9rOrFiHvUj4EeviT8UdA2b8b_FpiPofeNqRyWzNA9286ZNQ@mail.gmail.com>
2018-01-01  0:00   ` Nick Clifton
2018-01-01  0:00     ` Cary Coutant
2018-01-01  0:00       ` Florian Weimer
2018-01-01  0:00         ` Cary Coutant [this message]
2018-01-01  0:00           ` Florian Weimer
2018-01-01  0:00             ` Cary Coutant
2018-01-01  0:00               ` Florian Weimer
2018-01-01  0:00                 ` Cary Coutant
2018-01-01  0:00                   ` Florian Weimer
2018-01-01  0:00       ` Cary Coutant

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='CAJimCsETsrMRw8DuAngVR-EwJ_L9=yJGAcWnEdDhRNZQ-0+1qQ@mail.gmail.com' \
    --to=ccoutant@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=hjl.tools@gmail.com \
    --cc=nickc@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).