This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] ld: Add random filling for unspecified section contents
- From: Nick Clifton <nickc at redhat dot com>
- To: Andrew Burgess <andrew dot burgess at embecosm dot com>
- Cc: binutils at sourceware dot org
- Date: Fri, 5 May 2017 10:39:26 +0100
- Subject: Re: [RFC] ld: Add random filling for unspecified section contents
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nickc at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 932C681247
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 932C681247
- References: <firstname.lastname@example.org> <email@example.com> <20170426092640.GI27726@embecosm.com>
> 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
>> 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?)
> 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).