public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Stephen Casner <casner@acm.org>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: Problem with ld for PDP-11
Date: Thu, 13 Feb 2020 06:02:00 -0000	[thread overview]
Message-ID: <alpine.OSX.2.21.9999.2002122146060.48467@auge.attlocal.net> (raw)
In-Reply-To: <20200213002635.GA29647@bubble.grove.modra.org>

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

  reply	other threads:[~2020-02-13  6:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 20:30 Stephen Casner
2020-02-13  0:26 ` Alan Modra
2020-02-13  6:02   ` Stephen Casner [this message]
2020-02-13  6:58     ` Alan Modra
2020-02-13  7:18       ` Stephen Casner
2020-02-13  7:50         ` Alan Modra
2020-02-14 23:42           ` Stephen Casner
2020-02-15  0:11   ` Stephen Casner
2020-02-17 21:06     ` Stephen Casner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.OSX.2.21.9999.2002122146060.48467@auge.attlocal.net \
    --to=casner@acm.org \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).