public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: binutils@sourceware.org
Subject: Re: [RFC] ld: Add random filling for unspecified section contents
Date: Fri, 05 May 2017 09:39:00 -0000	[thread overview]
Message-ID: <5a0bdc01-02c0-0680-2111-1b1c2bafb520@redhat.com> (raw)
In-Reply-To: <20170426092640.GI27726@embecosm.com>

Hi Andrew,

> The situation in which I'm making use of this feature is really
> outside of the ELF.  I'm linking code for an embeded target where
> the code/data that is eventually loaded onto the device is extracted
> from the ELF, so there's no symbol table, of section/segment table to
> reveal any information.

But if the data is being extracted from an ELF file, why can't the 
extraction tool add in random data to pad out the rest of the data
section ?  It has the ELF headers available, so it must know the size
of the section.  [Basically I am trying to argue the case for not
adding a feature to the linker if it is not really necessary].  This
would also have the advantage that the enhanced extraction tool would
work with binaries produced by other linkers, or older versions of GNU
ld.


>> What about using jrand48_r instead ?
> 
> That I suspect will suffer from the same issue of unavailability on
> some targets.  The particular target that I know about would be Mingw
> (that is a target we support, right?)

Right.

> where as far as I can tell /
> figure out, there are very few random APIs available.  I don't
> directly have access to such a target for testing so I'm pretty
> limited in what I can figure out.

Hmm, no access to the target, a run-time environment without a full 
POSIX implementation and brand new linker feature.  What could go wrong ? :-)


>>> I'm wondering if the right thing to do is to add a reentrant random
>>> number API to libiberty and use that.

Have you tried asking the libiberty maintainers about this ?  It does
sound like something that they might find worthwhile.


> I originally avoided that as it seemed a little clunky, but, I suspect
> my only other option is writing a jrand48_r like thing in libiberty
> (which I'd rather avoid), so I've taken your suggestion and switched
> to a random/setstate/initstate solution.
> 
> Would you be OK with this in tree?

Well, I am still reluctant, on the grounds that it is adding a new feature
with a very limited use-set.  One thing that did occur to me however, was -
is it possible to use a linker plugin to achieve the desired effect ?  I
am just asking off the top of my head here, I have not actually checked to
see if it would be possible, but it would certainly avoid the feature-bloat
issue that I am worried about.  (FYI - I know that the plugin could not add
a new keyword to the linker script parser, but it might be able to add in
its own padding to data sections as they are read in, or linked, or it might
be able to overwrite the FILLed in data sections after they have been placed
into the linker map).

Cheers
  Nick

  reply	other threads:[~2017-05-05  9:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-14 22:40 Andrew Burgess
2017-04-20 13:43 ` Nick Clifton
2017-04-26  9:26   ` Andrew Burgess
2017-05-05  9:39     ` Nick Clifton [this message]
2017-05-09 16:36       ` Andrew Burgess
2017-05-15 15:58         ` Petr Ovtchenkov
2017-05-15 16:43           ` Nick Clifton
2017-05-16  7:24             ` Petr Ovtchenkov
2017-05-17 15:48               ` Andrew Burgess

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=5a0bdc01-02c0-0680-2111-1b1c2bafb520@redhat.com \
    --to=nickc@redhat.com \
    --cc=andrew.burgess@embecosm.com \
    --cc=binutils@sourceware.org \
    /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).