Problem with ld for PDP-11

[Stephen Casner]

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