From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85467 invoked by alias); 12 Feb 2020 20:30:00 -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 85455 invoked by uid 89); 12 Feb 2020 20:29:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=word's X-HELO: c.mail.sonic.net Received: from c.mail.sonic.net (HELO c.mail.sonic.net) (64.142.111.80) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Feb 2020 20:29:57 +0000 Received: from auge (75-25-121-24.lightspeed.snvaca.sbcglobal.net [75.25.121.24]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id 01CKToqp023711 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Feb 2020 12:29:50 -0800 Date: Wed, 12 Feb 2020 20:30:00 -0000 From: Stephen Casner To: binutils@sourceware.org Subject: Problem with ld for PDP-11 Message-ID: User-Agent: Alpine 2.21.9999 (OSX 301 2018-08-15) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2020-02/txt/msg00230.txt.bz2 Recently Nick Clifton applied a fix for Bug 20694 - "PDP11 TARGET_PAGE_SIZE is incorrect" that I filed 3+ year ago. Thanks! In testing that fix I discoverd another bug in the PDP11 code for which I have a proposed fix and would like your feedback. I also have some questions about the command line options that control the various magic numbers, but I will raise those questions separately. The newly discovered bug is that when I add the -s option to ld to skip output of the symbol table, the last byte of the .data section is been replaced by zero if that section is of even size (a multiple of 2 bytes long). I found the code that does this. Specifically for the case when no symbols are written, the 0 byte is written by this code in the else clause at line 3926 of bfd/pdp11.c: /* Write out the string table, unless there are no symbols. */ if (abfd->symcount > 0) { if (bfd_seek (abfd, obj_str_filepos (abfd), SEEK_SET) != 0 || ! emit_stringtab (abfd, aout_info.strtab)) goto error_return; } else if (obj_textsec (abfd)->reloc_count == 0 && obj_datasec (abfd)->reloc_count == 0) { bfd_byte b; b = 0; if (bfd_seek (abfd, (file_ptr) (obj_datasec (abfd)->filepos + exec_hdr (abfd)->a_data - 1), SEEK_SET) != 0 || bfd_bwrite (&b, (bfd_size_type) 1, abfd) != 1) goto error_return; } If the size of the .data section is odd, then the result of this code is to write a padding byte to make the size of the a.out file even. That is probably the intent of the code. But when I tested commenting out this else clause the a.out file still contained a zero padding byte there, which suggests that it may be safe to just remove this else clause. My first idea was to make the else clause conditional on whether the size of the .data section was odd, but from what I can see the size has already been rounded up by the time this code is reached and I could not find another variable that would hold the value before rounding. It appears that the bfd/pdp11.c file was created by copying and modifying aoutx.h; this work was done by Lars Brinkhoff years ago. The corresponding else clause in aoutx.h always appends one word's worth of zero bytes (typically 4) to the output. It looks like the intention is to pad the length of the ouput to a word boundary, but that would only be effective if there is some operation that truncates the output to the last whole word. I don't know the code well enough to find that. For the pdpd11 case, it looks like the last odd byte does get written with a zero pad even when the else clause is commented out. I asked Lars about deleting this else clause. He said he didn't remember the code well enough to say why that clause was included, but he agreed with my suggestion to remove it. Do any of you readers know how the padding and truncation in aoutx.h is implemented so you can direct me to the right part of the code to compare to the pdpd11 case? If you agree with the suggestion to delete this else clause in pdp11.c, how can I make that happen? Should I file a bug and include the change as a patch, or push it back from git somehow (I'm not a git expert)? It took a long time for bug 20694 to be addressed, and the fix was only committed after I happened to ask Lars about it, so I'm hoping to establish a more efficient and effective path for fixing this bug and for addressing the magic changes I'd like to propose. Thanks for your time. Steve Casner p.s. I'd be happy to provide the details of my testing if you care to see them.