From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15529 invoked by alias); 13 Feb 2020 06:02:09 -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 15519 invoked by uid 89); 13 Feb 2020 06:02:08 -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=casner, Casner, PDP11, digging X-HELO: d.mail.sonic.net Received: from d.mail.sonic.net (HELO d.mail.sonic.net) (64.142.111.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Feb 2020 06:02:06 +0000 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 01D62374016173 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 12 Feb 2020 22:02:03 -0800 Date: Thu, 13 Feb 2020 06:02:00 -0000 From: Stephen Casner To: Alan Modra cc: binutils@sourceware.org Subject: Re: Problem with ld for PDP-11 In-Reply-To: <20200213002635.GA29647@bubble.grove.modra.org> Message-ID: References: <20200213002635.GA29647@bubble.grove.modra.org> 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/msg00240.txt.bz2 On Thu, 13 Feb 2020, Alan Modra wrote: > On Wed, Feb 12, 2020 at 12:29:50PM -0800, Stephen Casner wrote: > > 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. Thanks for your prompt reply. Indeed, as I said in the later half of my previous message, my first idea was to make the else clause conditional on whether the size of the .data section was odd, but from what I could see the size had 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. So now I went digging my way back through the code sequence using printfs to find where the original data size gets rounded up. It turns out that the size of the data section is always even because the assembler "as" or "gas" always pads the data section with a zero byte if the size is odd, so the object file header always contains an even size for the .data section. That's because there is always relocation and symbol information following it. Therefore the size of the .data section in ld is always even so just removing that "else" clause would be a valid fix. How can I best 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)? Steve Casner