From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29873 invoked by alias); 9 May 2017 16:36:33 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 29842 invoked by uid 89); 9 May 2017 16:36:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=challenges, grounds, life, brand X-HELO: mail-wr0-f170.google.com Received: from mail-wr0-f170.google.com (HELO mail-wr0-f170.google.com) (209.85.128.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 May 2017 16:36:30 +0000 Received: by mail-wr0-f170.google.com with SMTP id z52so6533222wrc.2 for ; Tue, 09 May 2017 09:36:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YnKhazdFsz4Z4kKq7sL6MdZgOb/cypMRkucKVbNnrQU=; b=PJOeDi0Z57cqulZIXfxNF+adZ+0GkBrZyVJiFYdmURRah+JQ4qoQb9Eem7u9N/nTRz jB5B7d77otZffh8CRizmDtJD2kDT7MxwDn1yYRFZTnqQbb9KgGbOei5NiGiRV8kx74gp Vz02L9gR9VSfo+aehbjT6yKa6Je+ryqY2Kc2lWbAogWdyNjSpZ9privo0qjeGVZqaCXf +SSmVmfk8ISyzX5OgtVFNFDiznY8jfOJ6mmL5YWpZqpxBi/QqTkPc152YKOiXyTcG1+/ Mqp3e22e4ke4onHm6stMmzjep81KkwrvY9ofwF8z+eUlGfr7bQkXj6gMN3UBconK1jsC vX/A== X-Gm-Message-State: AODbwcA3PrKi0xTMTFCLKa2R7SbDCugpSnnyDppkoxlqGlBMi2mb+xuq ZrCnxncT8//13Q== X-Received: by 10.223.165.5 with SMTP id i5mr676055wrb.197.1494347791042; Tue, 09 May 2017 09:36:31 -0700 (PDT) Received: from localhost (host86-155-190-120.range86-155.btcentralplus.com. [86.155.190.120]) by smtp.gmail.com with ESMTPSA id e83sm1508854wmc.28.2017.05.09.09.36.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 09:36:29 -0700 (PDT) Date: Tue, 09 May 2017 16:36:00 -0000 From: Andrew Burgess To: Nick Clifton Cc: binutils@sourceware.org Subject: Re: [RFC] ld: Add random filling for unspecified section contents Message-ID: <20170509163622.GQ16262@embecosm.com> References: <1492209614-13110-1-git-send-email-andrew.burgess@embecosm.com> <20170426092640.GI27726@embecosm.com> <5a0bdc01-02c0-0680-2111-1b1c2bafb520@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a0bdc01-02c0-0680-2111-1b1c2bafb520@redhat.com> X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.6.1 (2016-04-27) X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00108.txt.bz2 * Nick Clifton [2017-05-05 10:39:26 +0100]: > 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. That's exactly what I do at the moment. This patch was just an attempt to fold the feature into the linker as it seemed like a fairly small extension which others might have found helpful (for embeded/security targets). > > > >> 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 ? :-) Indeed :) But what would life be without a few challenges! > >>> 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). OK, it doesn't sound like I'm going to convince you, so I'll park this patch for now. I appreciate the suggestions, but as I said above, I already have an out-of-linker solution for this problem, I was trying to move it in linker as it felt like a nice extension to the existing fill support. Thanks for taking the time to review this, Andrew