From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17474 invoked by alias); 13 Feb 2020 00:26:44 -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 17466 invoked by uid 89); 13 Feb 2020 00:26:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=word's, UD:p.s, brinkhoff, Recently X-HELO: mail-pl1-f195.google.com Received: from mail-pl1-f195.google.com (HELO mail-pl1-f195.google.com) (209.85.214.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 00:26:42 +0000 Received: by mail-pl1-f195.google.com with SMTP id t6so1591824plj.5 for ; Wed, 12 Feb 2020 16:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=aRXd82JI36oHovobAONgB3caAlO1kieWEv/WK8Dw1PU=; b=PQKLUcXCSzmNZL45SqxNdXqbQ/gtN6EqFxL5LrROpPJcggCvjIFuY396WJYAr2k7Mn GNGuciDK0AUNTdXccYI6MLm7V5/NTsGda+7TRpUEMrmKRwRf9xpcA0qjm5ObFG77K3pD UPEoINybWZA+D4q2Ynir9u1mWLvLBBOcRTH8ES11CHsDFcieCHIwZkL+WuzhQSC3wELR b8nXpf78CqMS89/LFKnFB1EDVxoium1wia7rlchKM2gFRJZXY08SCVD9EItk9zs5/w4D fSNao/vjar6Um9/K7Rp/sgcZRJpPt2wUiUmCE/7SuId3f8qVOkFtln+lHXFDUMXdfW2d Blpg== Return-Path: Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:f01a:fb53:d2a1:1c96]) by smtp.gmail.com with ESMTPSA id b15sm385349pft.58.2020.02.12.16.26.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2020 16:26:39 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 0E3998070B; Thu, 13 Feb 2020 10:56:36 +1030 (ACDT) Date: Thu, 13 Feb 2020 00:26:00 -0000 From: Alan Modra To: Stephen Casner Cc: binutils@sourceware.org Subject: Re: Problem with ld for PDP-11 Message-ID: <20200213002635.GA29647@bubble.grove.modra.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00232.txt.bz2 On Wed, Feb 12, 2020 at 12:29:50PM -0800, Stephen Casner wrote: > 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. Yes. The layout of a typical a.out file is header, text, data, relocs, symbols, string table. Since the code in question is handling the case where there are no relocs, symbols or string table, ie. the last thing in the file is data, I would guess that when the data section size is odd that the file size does not include the padding byte to make the data size even. But of course if the original data size is even you don't want to overwrite the last byte. The correct fix then is to add a check that the original data size was odd. That might not be easy as you may have lost the original data size by the time this code runs. The AOUT code is a bit of a mess. Oh, and if there is no data then it's the text section that might need extending. > 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. -- Alan Modra Australia Development Lab, IBM