From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by sourceware.org (Postfix) with ESMTPS id 87D29385DC00 for ; Fri, 3 Apr 2020 23:40:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 87D29385DC00 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=casner@acm.org Received: from auge (75-25-121-24.lightspeed.snvaca.sbcglobal.net [75.25.121.24]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id 033NegFa006381 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 3 Apr 2020 16:40:42 -0700 Date: Fri, 3 Apr 2020 16:40:42 -0700 (PDT) From: Stephen Casner To: Nick Clifton cc: binutils@sourceware.org Subject: Re: Proposed changes for pdp11 --*magic options In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.9999 (OSX 301 2018-08-15) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Sonic-CAuth: UmFuZG9tSVbEIUDEpiGsQJ7PNJVzdg7eMaaAXYrlOIJXWnx/JfL+MDJRYtpc1rbTeRhhivebVOXh2H7XCGLkjB5I+C5wiBil X-Sonic-ID: C;0pMKiAR26hGmIzoP5KAaoQ== M;4opOiAR26hGmIzoP5KAaoQ== X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 23:40:48 -0000 Nick, > First of all, please accept my apologies for taking such a long > time to reply to your email. Thanks for your reply. After there was no response for a while I went ahead and filed an enhancement bug with the same questions and you already added some comments there. > > - Rather than define another flag bit in bfd_target::object_flags, > > I'm copying the state of the separate_code boolean into a local > > variable in bfd/pdp11.c at _final_link() time for reference later > > in adjust_sizes_and_vmas() as the sections are written. > > I don't particularly like this approach, but I think that it is the > best solution without making major changes to the BFD library. Ideally > the link_info structure should be passed down to adjust_sizes_and_vmas > but this would mean changing target vectors. I wonder now whether there would be some other operations in the BFD menagerie that would need a new flag bit in bfd_target::object_flags in order to implement the right behavior. For example, an email in another forum today made me realize that pdp11-aout-objdump -h does not show the data at address 0 when the binary was made with my new --imagic option, but for that instance the problem must be not recognizing the different magic number. (I have not investigated yet.) > The diff itself is fine. I do have a few requests however: > > * Please could you add documentation to ld/ld.texi describing > the new option, what it does, and also mentioning that it is > only for the PDP11. What I was planning to do is add a new section 2.1.7 Options specific to PDP-11 target. > * It would be nice if you could create a new linker test to check > the behaviour of the new feature. I appreciate that there are no > PDP11 specific tests in the linker testsuite (or aout specific tests > for that matter). But there is no reason that you cannot add a > new directory and put the test(s) inside it. I'm willing to give this a shot. You may not have noticed a related question in my bug comment: Would it be reasonable to introduce changes to some of the existing tests to make them compatible with a 16-bit address space and reduce the number of failures for pdp11? Those are addresses and section sizes for the "MEMORY" and "MEMORY with symbols" tests that could be reduced to be less than 0x10000. Also there are some script tests with a souce file having a .long variable. If that was .word instead, then it would work for pdp11 as well. I have not explored yet to see if there is some global notion of word size that could be used by the test code or that should be used by nm so it does not show 32-bit addresses for pdp11. > * Please could you add a line to ld/NEWS mentioning the new feature. > > * If/when you do decide to submit the patch for inclusion, please > could you also provide ChangeLog entries describing what is happening. For both of these, do you just want the patch to include edits to these files? It seems that the final form of the entries depends upon the changes being merged into the official repository and committed to a release. Is there a way that I should provide the patch other than just a diff attached to the bug? I am familiar with forking and pull requests in github, but I don't know if there is some git-specific method for feeding changes back to binutils. > One final thing - which really should have been the first item - I do not > think that we have an FSF Copyright Assignment on file for you for > contributions to the binutils project. A change of this size/complexity > cannot be considered to be "obvious", so an assignment will be needed. > If you would like to fill out the form here and email it off, that will > start the process rolling: I did that already as soon as I saw your similar request in the bug comment. That was on 27 Mar 2020 with subject line "Stephen Lewis Casner" as requested. There will be additional files touched beyond those listed in that email in order to update the documentation and testsuite and possibly for objdump and nm as mentioned earlier. Another new question: ld help says: pdp11-aout-ld: supported targets: a.out-pdp11 srec symbolsrec verilog tekhex binary ihex plugin pdp11-aout-ld: supported emulations: pdp11 I'm not sure that the list of supported targets is true nor where the list is specified. Trying "--oformat srec" gives error file format not recognized, but so does "--oformat a.out-pdp11". -- Steve